Complex templates using loops and advanced logic are possible with Jinja2, as described in the documentation. Jinja2 templates are a very powerful way to render customized files out to hosts (or groups of hosts, if you want to use group variables that apply to multiple hosts). Once you run this playbook via ansible-playbook -i inventory.yml template.yml, the destination file on the remote system will have a completed configuration file, with all variables filled in, at /etc/keepalived/nf: cat /etc/keepalived/nf Notice that Jinja2 syntax is used to reference both built-in Ansible facts ( ansible_default_ipv4) and variables ( keepalived_state) that are provided via the vars key in the playbook YAML: vrrp_instance :VIP j2 suffix so that you know it is a Jinja2 template. This path contains the keepalived configuration file. Ansible is smart enough to automatically search for templates in specific known locations, such as templates/, so that you don't have to worry about typing the entire path. The source file is stored at templates/etc/keepalived/2. Just realize that the playbook below installs the keepalived application and writes a needed configuration file:. If you're not, then don't worry about it.
#Copy log template series#
If you've read my previous series about Linux high availability, then you're already familiar with the purpose of keepalived. The playbook below installs and configures keepalived. That might sound confusing to the new Ansible user, so I'll break it down a bit through an example. This enables you to use variables, such as Ansible facts, to customize a particular file for a specific server.
The template module also copies a file to a remote server, but it allows you to use Jinja2 to render a template to a file dynamically. You should never use a tool like Git to store files with sensitive information, such as passwords or private data.
#Copy log template code#
If you're using source code management, such as Git, for your Ansible playbooks, ensure that any files handled by the copy module are appropriate to put in source code. A binary application file that you want to copy exactly from your local system to remote systems.Base application configuration files that never vary between systems, such as an SSH configuration file that you want to keep consistent.Login banners and messages of the day (motd).The copy module is perfect for those files that are always consistent across all of your systems. The copy module is easy to use and requires little explanation: -Īfter running my Ansible playbook with ansible-playbook -i inventory.yml copy.yml, I have an updated motd file on the remote system: cat /etc/motd The copy moduleĪnsible's copy module does exactly what you expect: It copies a file from the local host to a remote server. I am executing these playbooks against a single host, as seen in my inventory file below: $ cat inventory.yml This article discusses some best practices for choosing between the Ansible copy and template modules.īefore I begin, let me show you the directory structure that I am using for this tutorial so you can follow along: $ tree Copying essential configuration files to remote servers is an excellent use case for those who are just starting their Ansible journey. So many things can be done in Linux using simple files. When it comes to transferring files to a remote system with Ansible, the copy and template modules are great tools for the job. Migrating to Ansible Automation Platform 2.A system administrator's guide to IT automation.
#Copy log template trial#
0 kommentar(er)
