Radware Cloud Application Protection Service Plans

 

Cloudflare Account Executive-Cloudflare Success Offerings

Ansible at Glance

Ansible is a combination of multiple pieces working together to become an automation tool. Mainly these are modules, playbooks, and plugins.

Modules are small codes that will get executed. There are multiple inbuilt modules that serve as a starting point for building tasks.

Playbooks contain plays which further is a group of tasks. This is the place to define the workflow or the steps needed to complete a process

Plugins are special kinds of modules that run on the main control machine for logging purposes. There are other types of plugins also.

The playbooks ran via an Ansible automation engine. These playbooks contain modules that are basically actions that run in host machines. The mechanism is followed here is the push mechanism, so ansible pushes small programs to these host machines which are written to be resource models of the desired state of the system.

What are the features of Ansible?

It has the following features:

• Agentless – Unlike puppet or chef there is no software or agent managing the nodes.
• Python – Built on top of python which is very easy to learn and write scripts and one of the robust programming languages.
• SSH – Passwordless network authentication which makes it more secure and easy to set up.
• Push architecture – The core concept is to push multiple small codes to the configure and run the action on client nodes.
• Setup – This is very easy to set up with a very low learning curve and any open source so that anyone can get hands-on.
• Manage Inventory – Machines’ addresses are stored in a simple text format and we can add different sources of truth to pull the list using plugins such as Openstack, Rackspace, etc.

 Explain Ansible modules in detail?

Ansible modules are like functions or standalone scripts which run specific tasks idempotently. The return value of these are JSON string in stdout and input depends on the type of module. These are used by Ansible playbooks.

There are 2 types of modules in Ansible:

• Core Modules

The core Ansible team is responsible for maintaining these modules thus these come with Ansible itself. The issues reported are fixed on priority than those in the “extras” repo.

• Extras Modules

The Ansible community maintains these modules so, for now, these are being shipped with Ansible but they might get discontinued in the future. These can be used but if there are any feature requests or issues they will be updated on low priority.

Now popular extra modules might enter into the core modules anytime. You may find these separate repos for these modules as ansible-modules-core and ansible-modules-extra respectively.

What is a YAML file and how do we use it in Ansible?

YAML or files are like any formatted text file with few sets of rules just like JSON or XML. Ansible uses this syntax for playbooks as it is more readable than other formats.

What are Ansible tasks?

The task is a unit action of Ansible. It helps by breaking a configuration policy into smaller files or blocks of code. These blocks can be used in automating a process. For example, to install a package or update a software

What is YAML

YAML is a common programing language as a result of it’s human-readable and simple to grasp. It can even be employed in conjunction with different programming languages.

YAML has options that come back from Perl, C, XML, HTML, and alternative programming languages. YAML is additionally a superset of JSON, thus JSON files ar valid in YAML.

Ansible uses YAML for writing playbooks by default. Ansible does not support json format as YAML is easy to read and write with the human-readable data format. Ansible playbooks contain yaml code to play and automate the process.

YAML files are more readable than JSON, However processing JSON files are faster compared with YAML files.

JSON is more of a data agreement format used to send and receive between client and server systems. YAML is more of configuration storing data for different environments like QA, STAGE, and Production for deployments and build process

Check your DNS MX Records online

 This test will list MX records for a domain in priority order.

MX Lookup Tool - Check your DNS MX Records online - MxToolbox

Migrating Jenkins from one server to another: There are multiple approaches

1.      METHOD 1: Using Thin backup plugin:

First you will have to install this plugin in both your server

o   On Source Jenkins go to ThinBackup → Backup Now

o   Copy from Jenkins Source Backup directory to Jenkins Target Backup Directory

o   On Target Jenkins go to ThinBackup → Restore, and then restart Jenkins service.

o   If some Plugins or Jobs are missing, copy the backup content directly to the target JENKINS_HOME.

o   If you had user authentication on the source Jenkins, and now locked out on the target Jenkins, then edit Jenkins config.xml, set <useSecurity> to false, and restart Jenkins.

 

2.      METHOD 2: (copying JENKINS_HOME)

o   Make zip/Archive of JENKINS_HOME and upload it to your storage location from the current server and download it back from the new server and place it in the correct place or Extract the archive into the new JENKINS_HOME directory

o   If you have already mounted volumes in external directory then take a snapshot of source and attach a volume made of that snapshot to new server

o   Do not forget to change the owner of the new Jenkins files : chown -R jenkins:jenkins $JENKINS_HOME

o   JENKINS_HOME is by default located in ~/.jenkins on a Linux installation

o   Ref: rsync -av username@old-server-IP:/var/lib/jenkins/ /var/lib/jenkins/

 

3.      METHOD 3: By using Job imports plugin

o   You need to install job import plugin on the server where you need to import jobs to.Then go to the plugin displayed on left side of Jenkins.

o   Enter url and authentication and jobs will be listed of remote server.

Select the jobs to be copied and done. Jenkins will copy the jobs to your server.

Jenkins API

 For job migration:

1. You can get the list of jobs installed on {SOURCE_JENKINS_URL} using a REST call, {SOURCE_JENKINS_URL}/view/All/api/json
2. Then you can get each job config.xml file from the jobs on {SOURCE_JENKINS_URL} using the job URL {SOURCE_JENKINS_URL}/job/{JOB_NAME}.
3. Use this config.xml file to POST the content of the XML file on {DESTINATION_JENKINS_URL} and that will create a job on {DESTINATION_JENKINS_URL}.

For plugin migration:

1. GET request: {SOURCE_JENKINS_SERVER}/pluginManager/api/json?depth=1 will get you the list of plugins installed with their version.

2. You can send a POST request with the following parameters to install these plugins.

final_url=`{DESTINATION_JENKINS_SERVER}/pluginManager/installNecessaryPlugins`

data=`<jenkins><install plugin="{PLUGIN_NAME}@latest"/></jenkins>` (where, latest will fetch the latest version of the plugin_name)

auth=`(destination_jenkins_username, destination_jenkins_password)`

header=`{crumb_field:crumb_value,"Content-Type":"application/xml”}` (where crumb_field=Jenkins-Crumb and get crumb value using API call {DESTINATION_JENKINS_SERVER}/crumbIssuer/api/json