rajeshkumar created the topic: Windows Installer Component Management
The Windows® Installer reduces the total cost of ownership (TCO) of your applications by increasing the ability of your customers to manage and maintain application components during setup and run time. The installation database tracks which applications require a particular component, which files comprise each component, where each file is installed on the system, and where component sources are located. This allows developers to author packages that provide the following benefits:
• Increased resiliency of applications. Use the installer to detect and reinstall damaged components without having to rerun setup. The installer checks the path of a component at run time. This frees applications from dependency on static file paths which commonly differ between computers and can point to missing components. For more information, see Resiliency.
• Installation-On-Demand. This feature set is not installed during setup but is specified in the database to be installed just-in-time for use if required by the application in the future. Users do not need to rerun setup. For more information, see Installation-On-Demand.
• Advertisement of shortcuts to features, applications, or entire products in the user interface. Users can install these on-demand by using the shortcuts. Users can also remove features, applications, or entire products on-demand. For more information, see Advertisement.
• Installation customization. An administrator can apply transforms to the database that tailor the installation for a particular group of users. For more information, see Customization.
• Easier deployment of application updates. Use the installer to update your products. For more information, see Patching and Upgrades.
• Feature shortcut display. The installer displays shortcuts to features that run locally with shortcuts to features that run remotely. Because the installation database specifies the run context of each feature, visibly equivalent entry points can be presented to users as needed.
• Keep usage metrics on features. Developers can provide an installation package that keeps usage count of a feature by all client applications and removes components that are not being used.
• Incorporate installations. Developers can incorporate the component management capabilities of the installer into their applications by authoring an installation package and by using the Installer Functions in their application code. The following figure illustrates an application requesting the installation of a feature.
Regards,
Rajesh Kumar
Twitt me @ twitter.com/RajeshKumarIn
Tag: Management
Top 5 Application Performance Management Tools

1. New Relic APM
- Application Monitoring
- Deployment Analysis, History, and Comparison
- Database Monitoring
- Availability & Error Monitoring
- Complete report
- Team Collaboration – Team can work together
- Secure
2. AppDynamics
- End-to-end transaction tracing
- Troubleshooting and control
- Code level visibility
- Scalability
- Dynamic baselining and alerting
- Data retention
3. Foglight

- Integrated transaction- and customer-centric application performance monitoring
- User Experience Monitoring
- Transaction DNA
- Advanced analytics
- Enhanced collaboration

- Application Centric Infrastructure Monitoring
- Synthetic Testing
- End user experience monitoring
- Deep dive diagnostic
- Track and alert on application health
- Group apps by business process
- Set thresholds to trigger alerts
- Ensure business services are meeting SLAs
- Supports monitoring of major application servers
- Synthetic transactions to monitor end-to-end performance
Top 5 Release Management Tools

It’s growing rapidly which means it’s really beneficial in “Software Development Life Cycle”,
So let’s have a look on to the benefits.
- Dashboards and Reports
- Environment Management
- Planning and Control
- Communication and Collaboration
- Managing Deployment and Task Lists
- Enterprise Scalability
2. ElectricFlow
- Microservices and Container Orchestration
- Shared Visibility
- Process as Code
- Advanced Deployment Strategies
- Enterprise Security and Compliance
- Automation at Any Scale
- Automated Rollbacks
- Environment Reservations and Calendaring
- Built-in Artifact Repository
3. BMC Release Process Management
- Easy to use
- Executable checklist
- Centralized management
- Meaningful metrics
- Extensive reach
- Better planning
4. URelease
- Multi-Application Continuous Delivery
- Impact Analysis
- Release Pipeline Visualization
- Release Gates
- Deployment Plans and Templates
- Federated Release Dashboard
5. XL Release
- End-to-end release dashboards
- Complex pipeline orchestration
- Automation that scales
- In-depth analytics and reports
- Enterprise auditability and controls
- Easy to use
Top 5 IT Management Tools | IT Management Software
IT Management Software | Top 5 IT Management Tools
- Servicenow
- BMC Remedy
- Jira
- Salesforce
- Sharepoint
Top 25 Chef configuration management interview questions and answers
Source – learn.chef.io
What is a resource?
Answer- A resource represents a piece of infrastructure and its desired state, such as a package that should be installed, a service that should be running, or a file that should be generated.
Question: What is a recipe?
Answer- A recipe is a collection of resources that describes a particular configuration or policy. A recipe describes everything that is required to configure part of a system. Recipes do things such as:
install and configure software components.
manage files.
deploy applications.
execute other recipes.
Question: What happens when you don’t specify a resource’s action?
Answer- When you don’t specify a resource’s action, Chef applies the default action.
Question: Are these two recipes the same?
package 'httpd'
service 'httpd' do action [:enable, :start] end
&&
service 'httpd' do action [:enable, :start] end
package 'httpd'
Answer-
No, they are not. Remember that Chef applies resources in the order they appear. So the first recipe ensures that the httpd package is installed and then configures the service. The second recipe configures the service and then ensures the package is installed.
Question: The second recipe may not work as you’d expect because the service resource will fail if the package is not yet installed.
Are these two recipes the same?
package 'httpd'
service 'httpd' do action [:enable, :start] end
package 'httpd'
service 'httpd' do action [:start, :enable] end
Answer-
No, they are not. Although both recipes ensure that the httpd package is installed before configuring its service, the first recipe enables the service when the system boots and then starts it. The second recipe starts the service and then enables it to start on reboot.
Are these two recipes the same?
file ‘/etc/motd’ do
owner ‘root’
group ‘root’
mode ‘0755’
action :create
end
file ‘/etc/motd’ do
action :create
mode ‘0755’
group ‘root’
owner ‘root’
end
Answer-
Yes, they are! Order matters with a lot of things in Chef, but you can order resource attributes any way you want.
Question –
Write a service resource that stops and then disables the httpd service from starting when the system boots.
Answer –
service ‘httpd’ do
action [:stop, :disable]
end
How does a cookbook differ from a recipe?
A recipe is a collection of resources, and typically configures a software package or some piece of infrastructure. A cookbook groups together recipes and other information in a way that is more manageable than having just recipes alone.
For example, in this lesson you used a template resource to manage your HTML home page from an external file. The recipe stated the configuration policy for your web site, and the template file contained the data. You used a cookbook to package both parts up into a single unit that you can later deploy.
How does chef-apply differ from chef-client?
chef-apply applies a single recipe; chef-client applies a cookbook.
For learning purposes, we had you start off with chef-apply because it helps you understand the basics quickly. In practice, chef-apply is useful when you want to quickly test something out. But for production purposes, you typically run chef-client to apply one or more cookbooks.
You’ll learn in the next module how to run chef-client remotely from your workstation.
What’s the run-list?
The run-list lets you specify which recipes to run, and the order in which to run them. The run-list is important for when you have multiple cookbooks, and the order in which they run matters.
What are the two ways to set up a Chef server?
Install an instance on your own infrastructure.
Use hosted Chef.
What’s the role of the Starter Kit?
The Starter Kit provides certificates and other files that enable you to securely communicate with the Chef server.
Where can you get reusable cookbooks that are written and maintained by the Chef community?
Chef Supermarket, https://supermarket.chef.io.
What’s the command that enables you to interact with the Chef server?
knife
What is a node?
A node represents a server and is typically a virtual machine, container instance, or physical server – basically any compute resource in your infrastructure that’s managed by Chef.
What information do you need to in order to bootstrap?
You need:
your node’s host name or public IP address.
a user name and password you can log on to your node with.
Alternatively, you can use key-based authentication instead of providing a user name and password.
What happens during the bootstrap process?
During the bootstrap process, the node downloads and installs chef-client, registers itself with the Chef server, and does an initial checkin. During this checkin, the node applies any cookbooks that are part of its run-list.
Which of the following lets you verify that your node has successfully bootstrapped?
The Chef management console.
knife node list
knife node show
You can use all three of these methods.
What is the command you use to upload a cookbook to the Chef server?
knife cookbook upload
How do you apply an updated cookbook to your node?
We mentioned two ways.
Run knife ssh from your workstation.
SSH directly into your server and run chef-client.
You can also run chef-client as a daemon, or service, to check in with the Chef server on a regular interval, say every 15 or 30 minutes.
Update your Apache cookbook to display your node’s host name, platform, total installed memory, and number of CPUs in addition to its FQDN on the home page.
Update index.html.erb like this.
<html>
<body>
<h1>hello from <%= node[‘fqdn’] %></h1>
<pre>
<%= node[‘hostname’] %>
<%= node[‘platform’] %> – <%= node[‘platform_version’] %>
<%= node[‘memory’][‘total’] %> RAM
<%= node[‘cpu’][‘total’] %> CPUs
</pre>
</body>
</html>
Then upload your cookbook and run it on your node.
What would you set your cookbook’s version to once it’s ready to use in production?
According to Semantic Versioning, you should set your cookbook’s version number to 1.0.0 at the point it’s ready to use in production.
What is the latest version of the haproxy community cookbook?
To know the latest version of any cookbook on Chef Supermarket, browse to its page and view the latest version from the version selection box.
Or, get the info from the knife cookbook site command, like this.
knife cookbook site show haproxy | grep latest_version
latest_version: http://cookbooks.opscode.com/api/v1/cookbooks/haproxy/versions/1.6.6
Create a second node and apply the awesome_customers cookbook to it. How long does it take?
You already accomplished the majority of the tasks that you need. You wrote the awesome_customers cookbook, uploaded it and its dependent cookbooks to the Chef server, applied the awesome_customers cookbook to your node, and verified that everything’s working.
All you need to do now is:
Bring up a second Red Hat Enterprise Linux or CentOS node.
Copy your secret key file to your second node.
Bootstrap your node the same way as before. Because you include the awesome_customers cookbook in your run-list, your node will apply that cookbook during the bootstrap process.
The result is a second node that’s configured identically to the first one. The process should take far less time because you already did most of the work.
Now when you fix an issue or add a new feature, you’ll be able to deploy and verify your update much more quickly!
What’s the value of local development using Test Kitchen?
Local development with Test Kitchen:
enables you to use a variety of virtualization providers that create virtual machine or container instances locally on your workstation or in the cloud.
enables you to run your cookbooks on servers that resemble those that you use in production.
speeds up the development cycle by automatically provisioning and tearing down temporary instances, resolving cookbook dependencies, and applying your cookbooks to your instances.
What is VirtualBox? What is Vagrant?
VirtualBox is the software that manages your virtual machine instances.
Vagrant helps Test Kitchen communicate with VirtualBox and configures things like available memory and network settings.
Verify that your motd cookbook runs on both CentOS 6.6 and CentOS 6.5.
Your motd cookbook is already configured to work on CentOS 6.6 as well as CentOS 6.5, so you don’t need to modify it.
To run it on CentOS 6.5, add an entry to the platforms section of your .kitchen.yml file like this.
--- driver: name: vagrant
provisioner: name: chef_zero
platforms: - name: centos-6.6 driver: box: opscode-centos-6.6 box_url: http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_centos-6.6_chef-provisionerless.box - name: centos-6.5 driver: box: opscode-centos-6.5 box_url: http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_centos-6.5_chef-provisionerless.box
suites: - name: default run_list: - recipe[motd::default] attributes:
In many cases, Test Kitchen can infer the box and box_url parameters, which specify the name and location of the base image, or box. We specify them here to show you how to use them.
Run kitchen list to see the matrix of test instances that are available. Here, we have two platforms – CentOS 6.5 and CentOS 6.6 – multiplied by one suite – default.
$kitchen list
Instance Driver Provisioner Verifier Transport Last Action default-centos-66 Vagrant ChefZero Busser Ssh <Not Created> default-centos-65 Vagrant ChefZero Busser Ssh <Not Created>
Run kitchen converge to create the instances and apply the motd cookbook.
$kitchen converge -----> Starting Kitchen (v1.4.0) -----> Creating <default-centos-66>... Bringing machine 'default' up with 'virtualbox' provider... [...] Running handlers: Running handlers complete Chef Client finished, 1/1 resources updated in 10.372334751 seconds Finished converging <default-centos-66> (3m52.59s). -----> Creating <default-centos-65>... Bringing machine 'default' up with 'virtualbox' provider... [...] Running handlers: Running handlers complete Chef Client finished, 1/1 resources updated in 5.32753132 seconds Finished converging <default-centos-65> (10m12.63s). -----> Kitchen is finished. (19m47.71s)
Now to confirm that everything’s working, run kitchen login. But this time, you need to provide the instance name so that Test Kitchen knows which instance to connect to.
$kitchen login default-centos-66 Last login: Wed May 13 20:15:00 2015 from 10.0.2.2 hostname: default-centos-66 fqdn: default-centos-66 memory: 469392kB cpu count: 1 [vagrant@default-centos-66 ~]$ logout Connection to 127.0.0.1 closed.$kitchen login default-centos-65 Last login: Wed May 13 20:28:18 2015 from 10.0.2.2 hostname: default-centos-65 fqdn: default-centos-65 memory: 469452kB cpu count: 1 [vagrant@default-centos-65 ~]$ logout Connection to 127.0.0.1 closed.
Chef configuration management interview questions and answers | Chef Interview Q&A
Source – learn.chef.io
What is a resource?
Answer- A resource represents a piece of infrastructure and its desired state, such as a package that should be installed, a service that should be running, or a file that should be generated.
Question: What is a recipe?
Answer- A recipe is a collection of resources that describes a particular configuration or policy. A recipe describes everything that is required to configure part of a system. Recipes do things such as:
install and configure software components.
manage files.
deploy applications.
execute other recipes.
Question: What happens when you don’t specify a resource’s action?
Answer- When you don’t specify a resource’s action, Chef applies the default action.
Question: Are these two recipes the same?
package 'httpd'
service 'httpd' do action [:enable, :start] end
&&
service 'httpd' do action [:enable, :start] end
package 'httpd'
Answer-
No, they are not. Remember that Chef applies resources in the order they appear. So the first recipe ensures that the httpd package is installed and then configures the service. The second recipe configures the service and then ensures the package is installed.
Question: The second recipe may not work as you’d expect because the service resource will fail if the package is not yet installed.
Are these two recipes the same?
package 'httpd'
service 'httpd' do action [:enable, :start] end
package 'httpd'
service 'httpd' do action [:start, :enable] end
Answer-
No, they are not. Although both recipes ensure that the httpd package is installed before configuring its service, the first recipe enables the service when the system boots and then starts it. The second recipe starts the service and then enables it to start on reboot.
Are these two recipes the same?
file ‘/etc/motd’ do
owner ‘root’
group ‘root’
mode ‘0755’
action :create
end
file ‘/etc/motd’ do
action :create
mode ‘0755’
group ‘root’
owner ‘root’
end
Answer-
Yes, they are! Order matters with a lot of things in Chef, but you can order resource attributes any way you want.
Question –
Write a service resource that stops and then disables the httpd service from starting when the system boots.
Answer –
service ‘httpd’ do
action [:stop, :disable]
end
How does a cookbook differ from a recipe?
A recipe is a collection of resources, and typically configures a software package or some piece of infrastructure. A cookbook groups together recipes and other information in a way that is more manageable than having just recipes alone.
For example, in this lesson you used a template resource to manage your HTML home page from an external file. The recipe stated the configuration policy for your web site, and the template file contained the data. You used a cookbook to package both parts up into a single unit that you can later deploy.
How does chef-apply differ from chef-client?
chef-apply applies a single recipe; chef-client applies a cookbook.
For learning purposes, we had you start off with chef-apply because it helps you understand the basics quickly. In practice, chef-apply is useful when you want to quickly test something out. But for production purposes, you typically run chef-client to apply one or more cookbooks.
You’ll learn in the next module how to run chef-client remotely from your workstation.
What’s the run-list?
The run-list lets you specify which recipes to run, and the order in which to run them. The run-list is important for when you have multiple cookbooks, and the order in which they run matters.
What are the two ways to set up a Chef server?
Install an instance on your own infrastructure.
Use hosted Chef.
What’s the role of the Starter Kit?
The Starter Kit provides certificates and other files that enable you to securely communicate with the Chef server.
Where can you get reusable cookbooks that are written and maintained by the Chef community?
Chef Supermarket, https://supermarket.chef.io.
What’s the command that enables you to interact with the Chef server?
knife
What is a node?
A node represents a server and is typically a virtual machine, container instance, or physical server – basically any compute resource in your infrastructure that’s managed by Chef.
What information do you need to in order to bootstrap?
You need:
your node’s host name or public IP address.
a user name and password you can log on to your node with.
Alternatively, you can use key-based authentication instead of providing a user name and password.
What happens during the bootstrap process?
During the bootstrap process, the node downloads and installs chef-client, registers itself with the Chef server, and does an initial checkin. During this checkin, the node applies any cookbooks that are part of its run-list.
Which of the following lets you verify that your node has successfully bootstrapped?
The Chef management console.
knife node list
knife node show
You can use all three of these methods.
What is the command you use to upload a cookbook to the Chef server?
knife cookbook upload
How do you apply an updated cookbook to your node?
We mentioned two ways.
Run knife ssh from your workstation.
SSH directly into your server and run chef-client.
You can also run chef-client as a daemon, or service, to check in with the Chef server on a regular interval, say every 15 or 30 minutes.
Update your Apache cookbook to display your node’s host name, platform, total installed memory, and number of CPUs in addition to its FQDN on the home page.
Update index.html.erb like this.
<html>
<body>
<h1>hello from <%= node[‘fqdn’] %></h1>
<pre>
<%= node[‘hostname’] %>
<%= node[‘platform’] %> – <%= node[‘platform_version’] %>
<%= node[‘memory’][‘total’] %> RAM
<%= node[‘cpu’][‘total’] %> CPUs
</pre>
</body>
</html>
Then upload your cookbook and run it on your node.
What would you set your cookbook’s version to once it’s ready to use in production?
According to Semantic Versioning, you should set your cookbook’s version number to 1.0.0 at the point it’s ready to use in production.
What is the latest version of the haproxy community cookbook?
To know the latest version of any cookbook on Chef Supermarket, browse to its page and view the latest version from the version selection box.
Or, get the info from the knife cookbook site command, like this.
knife cookbook site show haproxy | grep latest_version
latest_version: http://cookbooks.opscode.com/api/v1/cookbooks/haproxy/versions/1.6.6
Create a second node and apply the awesome_customers cookbook to it. How long does it take?
You already accomplished the majority of the tasks that you need. You wrote the awesome_customers cookbook, uploaded it and its dependent cookbooks to the Chef server, applied the awesome_customers cookbook to your node, and verified that everything’s working.
All you need to do now is:
Bring up a second Red Hat Enterprise Linux or CentOS node.
Copy your secret key file to your second node.
Bootstrap your node the same way as before. Because you include the awesome_customers cookbook in your run-list, your node will apply that cookbook during the bootstrap process.
The result is a second node that’s configured identically to the first one. The process should take far less time because you already did most of the work.
Now when you fix an issue or add a new feature, you’ll be able to deploy and verify your update much more quickly!
What’s the value of local development using Test Kitchen?
Local development with Test Kitchen:
enables you to use a variety of virtualization providers that create virtual machine or container instances locally on your workstation or in the cloud.
enables you to run your cookbooks on servers that resemble those that you use in production.
speeds up the development cycle by automatically provisioning and tearing down temporary instances, resolving cookbook dependencies, and applying your cookbooks to your instances.
What is VirtualBox? What is Vagrant?
VirtualBox is the software that manages your virtual machine instances.
Vagrant helps Test Kitchen communicate with VirtualBox and configures things like available memory and network settings.
Verify that your motd cookbook runs on both CentOS 6.6 and CentOS 6.5.
Your motd cookbook is already configured to work on CentOS 6.6 as well as CentOS 6.5, so you don’t need to modify it.
To run it on CentOS 6.5, add an entry to the platforms section of your .kitchen.yml file like this.
--- driver: name: vagrant
provisioner: name: chef_zero
platforms: - name: centos-6.6 driver: box: opscode-centos-6.6 box_url: http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_centos-6.6_chef-provisionerless.box - name: centos-6.5 driver: box: opscode-centos-6.5 box_url: http://opscode-vm-bento.s3.amazonaws.com/vagrant/virtualbox/opscode_centos-6.5_chef-provisionerless.box
suites: - name: default run_list: - recipe[motd::default] attributes:
In many cases, Test Kitchen can infer the box and box_url parameters, which specify the name and location of the base image, or box. We specify them here to show you how to use them.
Run kitchen list to see the matrix of test instances that are available. Here, we have two platforms – CentOS 6.5 and CentOS 6.6 – multiplied by one suite – default.
$kitchen list
Instance Driver Provisioner Verifier Transport Last Action default-centos-66 Vagrant ChefZero Busser Ssh <Not Created> default-centos-65 Vagrant ChefZero Busser Ssh <Not Created>
Run kitchen converge to create the instances and apply the motd cookbook.
$kitchen converge -----> Starting Kitchen (v1.4.0) -----> Creating <default-centos-66>... Bringing machine 'default' up with 'virtualbox' provider... [...] Running handlers: Running handlers complete Chef Client finished, 1/1 resources updated in 10.372334751 seconds Finished converging <default-centos-66> (3m52.59s). -----> Creating <default-centos-65>... Bringing machine 'default' up with 'virtualbox' provider... [...] Running handlers: Running handlers complete Chef Client finished, 1/1 resources updated in 5.32753132 seconds Finished converging <default-centos-65> (10m12.63s). -----> Kitchen is finished. (19m47.71s)
Now to confirm that everything’s working, run kitchen login. But this time, you need to provide the instance name so that Test Kitchen knows which instance to connect to.
$kitchen login default-centos-66 Last login: Wed May 13 20:15:00 2015 from 10.0.2.2 hostname: default-centos-66 fqdn: default-centos-66 memory: 469392kB cpu count: 1 [vagrant@default-centos-66 ~]$ logout Connection to 127.0.0.1 closed.$kitchen login default-centos-65 Last login: Wed May 13 20:28:18 2015 from 10.0.2.2 hostname: default-centos-65 fqdn: default-centos-65 memory: 469452kB cpu count: 1 [vagrant@default-centos-65 ~]$ logout Connection to 127.0.0.1 closed.
Top 5 Configuration Management Tools
Top 5 Configuration Management Tools
In computing, Puppet is an open-source configuration management utility. It runs on many Unix-like systems as well as on Microsoft Windows, and includes its own declarative language to describe system configuration.
Puppet is produced by Puppet Labs, founded by Luke Kanies in 2005. It is written in Ruby and released as free software under the GNU General Public License (GPL) until version 2.7.0 and the Apache License 2.0 after that.
What started out as a popular DevOps tool has quickly become a movement. Written in Ruby, like Chef, Puppet also comes in both an open source and enterprise version. However, where Chef has a healthy offering of features across both open source and enterprise versions, Puppet has placed the majority of its feature set into enterprise status. Features that the open source version comes with include provisioning (Amazon EC2, Google Compute Engine), configuration management (operating systems and applications) plus 2,000+ pre-built configurations on Puppet Forge. Considerably more features are available for the enterprise version, including the open source features plus graphical user interface, event inspector (visualize infrastructure changes), supported modules, and provisioning (VMware VMs). Configuration management (discovery, user accounts), orchestration, task automation, role-based access control (with external authentication support) are also included. Puppet enterprise has a unified cross-platform installer of all components and support.
Offered as both an open source and enterprise product, Chef is a powerful tool for full IT infrastructure configuration management. With open source Chef at the heart of both offerings, shared features include a flexible and scalable automation platform, access to 800+ reusable cookbooks and integration with leading cloud providers. Chef also offers enterprise platform support, including Windows and Solaris, and allows you to create, bootstrap and manage OpenStack clouds. It has easy installation with ‘one-click’ Omnibus Installer, automatic system discovery with Ohai, text-based search capabilities and multiple environment support. Other notable features inclyde the “Knife” command line interface, “Dry Run” mode for testing potential changes, and the ability to manage 10,000+ nodes on a single Chef server. Features only available in the enterprise version of Chef include availablility as a hosted service, enhanced management console, centralized activity and resource reporting, as well as “Push” command and control client runs. Multi-tenancy, role-based access control (RBAC), high availability installation support and verification, along with centralized authentication using LDAP or Active Directory are included with Chef enterprise.
Ansible is a model-driven configuration management tool that leverages SSH to improve security and simplify management. In addition to configuration management, it is capable of automating app deployment (even multi-tier deployment), workflow orchestration and cloud provisioning, hence the company likes the tool to be categorized as an “orchestration engine.” Ansible is built on five design principles including ease of use (doesn’t require writing scripts or custom code), low learning curve (both for sysadmins and developers), comprehensive automation (allowing you to automate almost anything in your environment), efficiency (since it runs on OpenSSH it doesn’t rely on memory or CPU resources), and security (it is inherently more secure because it doesn’t require an agent, additional ports or root level daemons). As many other open source projects, Ansible has a paid product that comes in the form of a web UI called Ansible Tower.
One of the earliest full-featured configuration management systems out there, CFEngine has gone through several iterations and maintained relevance as OS have gone from the local data center to the cloud. At the heart of the infrastructure automation framework, CFEngine is also a modeling and monitoring compliance engine, capable of sitting on a small footprint. As recommended by CFEngine, steps toward identifying an initial desired state include: 1) model the desired state of your environment; 2) simulate configuration changes before committing them; 3) confirm the desired state and set for automatic self-healing; 4) collect reports on the differences between actual and desired states. CFEngine has a library of reusable data-driven models that will help users model their desired states. These infrastructure patterns are designed to be reusable across the Enterprise.
As part of a larger, enterprise ready application, the configuration management piece of Salt is as robust and feature-full as would be expected. Built upon the remote execution core, execution of the system occurs on “minions” which receives commands from the central Salt master and replies with the results of said commands. Salt support simultaneous configuration of tens of thousands of hosts. Based upon host “states”, no programming is required to write the configuration files, which are small and easy to understand, that help identify the state of each host. Additionally, for those who do program, or admins who want to have more control and familiarity with their configuration files, any language can be used to render the configurations.
Ways to Perforce server Disk Space Cleanup and Repos Size Management
DRAFT VERSION
- Cleaning up Old Checkpoints
- Playing with Symlink(Softlink) and Redirecting the ROOT folder to drive where we have enough place.
- Deleting db.have and recreate it manually
- Display disk space information on the server using “p4 diskspace”
- Display size information for files in the depot using “p4 sizes”
Chef configuration management | Chef Training | Chef Course | Online | Classroom
This course aims to prepare key development, engineering, and operations staff to use Chef to write infrastructure. Each of the core units in the course has hands on exercises to reinforce the material. You will learn Chef by using it. At the end of the class, students will have a code repository that can be used and modified to solve real business problems.
Click Here
Course agenda:
Day 1:
- What Is Configuration Management?
- Why You Need a Configuration Management Tool to Automate IT
- What Is Chef?
- Why Chef Might Be a Good Tool for Your Enterprise
- Where Do We Go From Here?
- Chef Development Tools
- Install and Configuration Chef Development Tools on Windows
- Install and Configuration Chef Development Tools on Linux
- Overview of Ruby
- Ruby Syntax and Examples
- Chef Syntax and Examples
- Working with Knife
- Writing First Chef Recipe
- Chef and Its Terminology
- Attributes
- Metadata
- Recipes
- Resources
- Templates
- Definitions
- Recipes
- Writing recipes
- Cookbook Dependencies
- Controlling Impotency
- Notifications
- Template Variables
Day 2:
- Cookbooks
- Using Cookbooks
- Windows – IIS, MSI, Exe, Zip files, Tomcat,
- Linux – RPM, Shell Script, Yum Repos,
- Common – SVN, Vagrant, Test Kitchen
- Introducing Vagrant & Virtualbox
- Introducing Test Kitchen
- Spinning up your first Virtual Machine
- Introducing OpsCode
- Developing a Cookbooks
- Developing Your First Cookbook
- Writing a Recipe
- Creating the Index File
- Changing the Metadata
- Uploading the Cookbook
- Running the Cookbook
- Add an Attribute
- Add a Resource to the Default Recipe
- Add the Template File
- Uploading and Running the Cookbook
- Using Environments
- Modeling your infrastructure
- Roles
- Implementing a role
- Determining which recipes you need
- Applying recipes to roles
- Mapping your roles to nodes
- Environments
- Organizing your configuration data
Day 3:
- Cloud Provisioning Using Chef
- Provisioning Using Vagrant and Chef
- Providers and Provisioners
- Installing Vagrant
- Configuring Vagrant
- Vagrant Provisioning Using Chef
- AWS and Chef Provisioning Using Vagrant
- Provisioning Using Knife
- Troubleshooting and Debugging
- Chef Troubleshooting and Debugging
- Debugging Chef Client Run
- Debugging Recipes Using Logs
- Debugging Recipes Using Chef Shell
- Troubleshooting Chef Client
- Recipe Inclusion
- Data Bags
- Search Roles
- Configuring Services like Apache
- Deployment using chef
- Looking at your application deployment cookbook
- Deployment using zip/tar files. E.g: Apache Tomcat deployment and configured as service.
- Windows – Configuring Services like IIS
- Dependencies Management
- Integrating with the Cloud
- Amazon EC2
- Rackspace Cloud
Release management with Build Forge e-Kit
To learn more about IBM® Rational® solutions for deployment planning and automation, take advantage of these additional resources:
- Analyst study: Demonstrated benefits of software delivery automation – Hurwitz & Associates interviewed customers from various industries who have implemented IBM® Rational® Build Forge® and IBM Rational Automation Framework for WebSphere®. The results of the study demonstrate that companies are indeed changing their approach to the build and deployment process to remain competitive.
- Value estimator: Rational software delivery automation – Learn how IBM automation software can help you gain productivity and drive real ROI.
- Webcast: Streamlined build and deployments powered by Jazz – IBM experts describe a step-by-step approach to plan-driven deployment automation.
Visit the Rational deployment planning and automation web page for more information.
Contact a Rational sales specialist.