Transcript
  • Servers and Tools

Templates

From the class:  Ansible

A really common use case in Ansible or in provisioning any deployment environment is copying a template of some sort up to the server. And a template could be the settings for your application, like in this role that I've created for our app. In this case, we're going to upload a JSON file for settings that our application will use.

But it could be a service file to start and stop an application with system D, or it might be an Nginx configuration file, or any other kind of configuration. So in this role, I've started it off here with a name, install app settings. And I want to create a file under a folder called Templates.

And that's where we can put any kind of templates that will go through the Jinja2 templating engine before they get uploaded to the server. And I'll add a file to that folder called settings.json. And I'll give it a file extension of j2. That's the extension for the Jinja2 templating engine so that our fellow colleagues can see that this is a template.

We'll fill this template out in a second. But let's go ahead and write the task to install it. I'm going to use a new module called the template module. And the template module takes a couple of options. The first one is going to be source. And the source is going to be the name of the template that we're going to upload.

Now, I don't need to type templates settings here because Ansible already knows to look in the Templates folder. So I can just say settings.json.j2. And then I need to give it a destination option. And this is where we want to put the settings file.

In this case, I'm going to put it under the app path in the config directory. And we'll name it settings.json. Just like with the file module, the template module takes an owner option as well. And this time, the owner can be Vagrant. Or just like last time, the group can be ADM for admin.

And we'll give it a file mode. This time, we can just use 0. The owner can read. The group can read. And everybody else can't even see the settings file. So this would be a security precaution.

Oftentimes in this settings file for the application, we're going to put things like the database password and the database user name. So you really want to make sure that no one else has access to that. Now let's add a very basic settings file just so that we can see whether it's working.

I can just use regular JSON syntax here, but it's going to be interpolated. This file will be run through the Jinja2 templating engine so variables can be interpolated inside of here. Let's create a variable called database name. So I'll call this database name. And the value will be something that comes from a variable db name.

Get rid of that space. And then we can go over to the environments variable section that we have under group vars. And I'll create a new variable called database name. And for now, I'll just make this the same as the app. And maybe I also want to say what environment it's for. So app_environment.

And in the playbook site.yml, I really only need that settings role to apply to the application role. So I'll use another entry. The host will be app. And the roles for the app will be settings. So for the application now, the application role will get the node JS project and now settings.

And let's run it and make sure that this works. I'll filter by tags. So we just run that new task. And it should create a settings.json file that it runs through the Jinja2 templating engine so we get the actual values. And it looks like we get another file permission error here.

I often forget that I need to use sudo privileges. So if you get an error message here that says the change group failed, you probably have to just go back and into the settings role, into the tasks, and make sure that we become the sudo user in order to do this. And let's run the task one more time.

And this time, it should succeed. Great. That time, we see that both the app servers are changed. And just to make sure, let's go ahead and ssh into them, into one of them. So we can vagrant ssh into app one local and go check out that file that got uploaded.

We'll change into the serv emind config directory and make sure that there's something there. And if we cat settings.json to the standard output, we see that it's been replaced with the actual database name. And looking at the file permissions, only the owner and the group owner have read and write privileges. And everybody else does not.

So templates are a great way to upload configuration files and other types of files where we need to interpolate variable values into the configuration file.