8i | 9i | 10g | 11g | 12c | 13c | 18c | 19c | 21c | 23c | Misc | PL/SQL | SQL | RAC | WebLogic | Linux
Ansible : Ad Hoc Commands
This article demonstrates how to run ad hoc commands using Ansible. It is based on the Introduction to ad hoc commands documentation, but amended for the infrastructure described in the Ansible : First Steps article.
Related articles.
Packages
We install the "nginx" package on all the hosts in the "appservers" group using the "dnf" module. On a previous release we would use the "yum" module. In the arguments we include the name of the package and the state we want. For an install the state is "present" or "latest". Notice we have used the --become flag, which tells Ansible it needs to run the command as the root user. On these VMs our user can sudo without a password, but if it required a password we could include the --ask-become-pass flag, and we would be prompted for the password for the privilege escalation.
$ ansible appservers -m dnf -a "name=nginx state=present" --become
We update an existing package using the state "latest". As mentioned before, this will install the package if it is not already installed.
$ ansible appservers -m dnf -a "name=nginx state=latest" --become
We remove a package using the state "absent".
$ ansible appservers -m dnf -a "name=nginx state=absent" --become
We update all the packages on the server using a wildcard name and the state of "latest".
$ ansible appservers -m dnf -a "name=* state=latest" --become
Files
We create a file on the local server.
$ touch /tmp/my-file.txt
We copy the file to all the hosts in the "appservers" group. This is like using SCP to copy the file.
$ ansible appservers -m copy -a "src=/tmp/my-file.txt dest=/tmp/my-file.txt"
We change the permissions and ownership on the remote files. Notice we use --become, to elevate the privileges.
$ ansible appservers -m file -a "dest=/tmp/my-file.txt mode=777 owner=root group=root" --become
We remove the file from the remote servers. Since the file is now owned by root, we need to use elevated privileges.
$ ansible appservers -m file -a "dest=/tmp/my-file.txt state=absent" --become
Users and Groups
All the actions require elevated privileges, so the commands include the --become flag.
Create some groups on all database hosts using the "group" module.
$ ansible databases -m group -a "name=oinstall gid=54321" --become $ ansible databases -m group -a "name=dba gid=54322" --become $ ansible databases -m group -a "name=oper gid=54323" --become
Create a user, who is part of those groups on all database hosts, using the "user" module. Using the password of "*" means it's a disabled account.
$ ansible databases -m user -a "name=oracle password='*' uid=54321 groups='oinstall,dba,oper'" --become
Remove the user.
$ ansible databases -m user -a "name=oracle state=absent" --become
Remove the groups.
$ ansible databases -m group -a "name=oinstall state=absent" --become $ ansible databases -m group -a "name=dba state=absent" --become $ ansible databases -m group -a "name=oper state=absent" --become
Services
We install NGINX on all hosts in the "appservers" group using the "dnf" module.
$ ansible appservers -m dnf -a "name=nginx state=present" --become
We start, restart and stop NGINX on all hosts in the "appservers" group using the "service" module.
$ ansible appservers -m service -a "name=nginx state=started" --become $ ansible appservers -m service -a "name=nginx state=restarted" --become $ ansible appservers -m service -a "name=nginx state=stopped" --become
We remove NGINX from hosts in the "appservers" group.
$ ansible appservers -m dnf -a "name=nginx state=absent" --become
Reboot Servers
Servers can be rebooted using using the "reboot" command with the default command module. This will typically return an error, as the host is no longer available for SSH, but the servers are rebooted as requested.
$ ansible databases -a "/sbin/reboot" --become database1.localdomain | FAILED | rc=-1 >> Failed to connect to the host via ssh: ssh: connect to host database1.localdomain port 22: Connection refused $
When these commands are run as part of a playbook they can be made to tolerate the outage.
What Next
There are lots of modules, and we can use the default command module to run any Linux command, so we are really not limited by what operations we can perform. There is an index of modules here.
In many cases we should avoid ad hoc commands and write playbooks to hold the configuration of servers, which can be checked into version control.
For more information see:
Hope this helps. Regards Tim...