When we talk about Ansible, it can be easily said that it is undoubtedly the simplest way to help deploy all our applications. It also along with it gives us the whole power to deploy many multi-tier applications very reliably and consistently and that too, all from one common framework. You can also along with it configure all the needed services as well as the push application artifacts too just from this one common system.
So now rather than just writing the custom code so as to automate your systems as you prefer to, your team shall write easy and simple task descriptions so that even the newest team member who is not quite known to it can to understand on the very first read and so this shall be saving not only up-front costs, but along with it, this shall also be making it much easier to react to the change over time.
Ansible really allows you to write the 'Playbooks' that are actually descriptions of the desired state of your systems, and that are usually kept in the source control. The ansible then after that does the very hard work of simply getting your systems to that needed state, no matter what kind of state they are actually currently in. So the playbooks shall also make your installations, or the upgrades and may be the day-to-day management repeatable and reliable and constructive too.
Playbooks are actually quite simple to write and also maintain. Most of these users become really productive just with Ansible just after a little time after, let's say only a few hours. Also, the ansible uses the same tools that you are most likely to be already using on a daily basis and also the playbooks that are written too in a very natural language so that then is very easy to evolve and edit.
Also, the other great thing about Ansible is that the Ansible is completely agent-less, and that means that you don’t have to install any software on your already managed hosts. Simply, all of the commands are run through the Ansible via the SSH and also, if the Ansible needs updating, then you only need to really update your single control machine. And that actually makes the task many times easier to do.
Also, the commands that you shall be executed via the Ansible are actually very important potent thus allowing anyone to very safely run them multiple times without anything really being changed, only unless the changes are required. On just needs to ensure that the Nginx is actually installed on all hosts. So for that, one just has to run all of the commands and then automatically the Ansible will make sure that only those that are really missing, the software does install it. And as such, all the other hosts will remain simply untouched and the work shall progress further.
Ansible Installation:
Well, for the installation, we need to actually set up a single control mechanism that we will use to simply execute our commands with. So just install the Ansible locally on OS X, but any platform that is with Python installed however excluding the Windows.
So first ensure that the pip is installed. And then install the Ansible. And then, once the installation has completed you also can verify that everything is installed correctly. Also, Now that the Ansible is also setup, we just need a few servers along with it to work with. So for that purpose, you need to fire up just three small Digital Ocean droplets too unto 14.04.4 x64 which are installed. Then also add your public key so that it can be copied to each of the hosts during the droplet creation. And this will ensure that we can SSH in via Ansible using simply just the root user without really providing a password later on. And so once, they’ve finished provisioning you’ll also be presented with the IP addresses too.
Inventory Setup:
For the inventory setup, Ansible just uses a simple inventory system to manage all your hosts. So this allows you to organize the hosts into the needed logical groups and negates the need to actually remember the individual IP addresses or the domain names.
So let’s say that one is a proud owner of a fleet of the Rackspace servers. So for the automated deployment of the script through the Ansible, or for the deployment, you can just simply just by manual set up do the configurations, or the installations and the applications just for every server. Or, you can also do something which is infinitely more scalable: like you can also use a very free, open source configuration management tool and then do the orchestration tool that is both simple and very easy to learn. So it is quite easy to deploy the script through the Ansible.
An overly general overview is that there are such several popular programs too for the configuration/orchestration, including Docker, Chef, Puppet, Salt and many others but the Ansible is actually a great choice for its simplicity and the scalability too.
With Ansible, you also have an “Ansible Server,” which is actually the computer running your commands, and also your remote hosts, which are also the computers being configured, although you can easily run Ansible tasks just on your local machine. Ansible also uses SSH to communicate between the Ansible server and also the remote hosts, so simple when you run a playbook, so the commands are executed on your remote host. Ansible owes its very high scalability to its agent-less design and so the high potential for playbook reuse. And so becomes quite easy to use.
So how can I use Ansible?:
In the simplest form, when you need simply three components: an Ansible server, remote hosts and a playbook too. So when you run your Ansible playbook, (the set of instructions that helps configures your cloud instances and your Ansible server will also then need to simply connect with each instance. So setting up the remote connection is as easy as setting up the password-less login with the SSH keys between your Ansible server and your remote hosts too. Also if you have such a use case where you easily cannot (or will not) use the SSH keys, you can also still use the passwords, and either have an Ansible prompt that you can use for passwords at runtime or store them in a file — although this is not recommended for security or, honestly, convenience.
The tasks however you want to get executed are actually defined separately from the list of the computers you want to be configured: and you provide Ansible with a very standalone inventory file of the hostnames. Also, an inventory file is a simple text file that actually lists the IP address or the hostnames of the servers where you’re deploying the needed code too.
Ansible host file:
A host file can be as simple as this. Also, you can group your hosts too in your inventory under the headings too, if you want to run the certain type of the Ansible tasks for certain host groups. Also, you can specify your servers too in the default hosts location (/etc/ansible/hosts), or you can feed your file it too to the Ansible when you deploy, with “- I inventory.txt”
Action!- But how do you really tell that Ansible what actions to take on the server? You can also write a playbook. An Ansible playbook is also written in a very simplified subset of YAML, which is also highly readable and much easier to pick up.
The other great point is that the batteries are included too. So there is leverage of one giant toolbox. Also, the shipping with over the 1,300+ modules in the multiple core distribution too. Also, along with it, the Ansible provides a vast library of the building blocks for managing all kinds of multiple IT tasks and also the network software. With the Ansible Galaxy, chances are also that there are community-contributed roles that can help get you started even faster.
Comments
Post a Comment