Introducing DevOps for Developers

Rendering Templates in a Dockerfile

Erik Reinert

Erik Reinert

Introducing DevOps for Developers

Check out a free preview of the full Introducing DevOps for Developers course

The "Rendering Templates in a Dockerfile" Lesson is part of the full, Introducing DevOps for Developers course featured in this preview video. Here's what you'd learn in this lesson:

Erik demonstrates implementing the ability for the CLI tool to read template files to generate the new dockerfile.


Transcript from the "Rendering Templates in a Dockerfile" Lesson

>> So we've gotten that far, but we need to take one step further, which is, we need to actually make it so that the template files are then read by the CLI tool, and then we create our new Docker file basically from that, right? So to do that, what we're gonna do is we need another tool.

So I'm gonna use something that I prefer, you guys have probably heard the term Jinja, very common way of doing templating in programming. This is hands down one of the most, just standardized ways of templating that we use today. And when I tell you that you can build the CLI tool in any language, I mean, you can.

[LAUGH] You just need to be able to template, you need to be able to describe a domain specific language, and you need to be able to then generate the template file. So If you wanted to, you could do this in Python, you could do this in Go, you could do this in Rust.

You could do this in any language you want. For me, however, I'm not a big fan of Jinja because I've used it for so long. [LAUGH] And so there's actually another one that I really like that's actually made by Mozilla, and it's called Nunjucks. And it basically underneath the hood is Jinja, it's just a little bit nicer, where you can just really lean on it, its configuration, it's just a little simpler to work with.

So we're gonna get started with this as well, right? And so just like I did before, I'm just gonna npm install Nunjucks. So I'll just do yarn add nunjucks. And I think it actually also wants me to add type, so let's just go ahead and do that too.

Dev@types. Cool, cool, okay. And so, There's actually a nice thing about it as well, which is you can configure it to just always know where the directory of all your templates are. So you might have noticed that I wrote the readFileSync, but I didn't write the readFileSync for the other files, right, like the template files.

That's because ideally, you could really just use a templating engine to do that. And so for example, I believe it's pas, I don't remember exactly where it is. Let me see here. Import from, Nunjucks, and then this should be configure. There we go. Okay, so what we're gonna do is we're gonna give it the path.

We're gonna say template. Sorry, templates, that's where our templates are. And then at this point, anytime I try generating a template, all I have to do is give it the file name, and Nunjucks knows how to take care of the rest. So when we talk about needing a ton of templates and how to manage them and having code around that, that's really easy.

Leaning on a templating engine like Nunjucks or Jinja or something like that could be super helpful. And again, this whole CLI tool is 30 lines of code, so it's really not much. So once we've got that, we can actually start working with our templates if we wanted to.

So if I just did render, I'm grabbing the render function, right? And this render function is another function in Nunjucks, and it does really pretty much what it says. It's gonna take a template file and it's gonna render it for you. And so in this case, what we wanna do is we wanna say Dockerfile, right, because that's our template, and then we wanna give it some parameters.

Now if we go to the Dockerfile here, we see that we have a service_name, and a service_type, right? So we need to at least give it a service_name, oops, service_name. And then we also need to give it a service_type, right? Problem is, that doesn't necessarily match our DSL exactly.

So we have a couple of options we can do here. The first one is we could just change it, so it's in camel case or in snake case or whatever or you just change it here as well. So in this, what we could do is, we could just say ServiceType.

And I would recommend this actually, I would. I wouldn't try and mesh conventions and stuff like that just to save yourself the hassle of wondering what was wise. And so now we can just literally use ServiceName, ServiceType like this. And we'll do configurationData, ServiceName, configurationData, ServiceType, okay? Is this gonna work here?

Hold on, there you go. Do we think this will work? Look at the file on the right. And then look at the file on the left. What's wrong?
>> ServiceName and Name?
>> Yep, yep, so this is a caveat to this approach. [LAUGH] You break the DSL, it breaks everything.

I've done that before, it's not fun [LAUGH], especially if you commit it. And this is another point of having these types of centralized automations. You need to make sure they're reliable. You need to make sure that you can consistently rely on them and so that your developers basically don't deal with what Zuckerberg and The Social Network was worried about.

People caring to use it cuz it don't work, that's a massive thing in DevOps. It's a massive thing in DevOps to be not only building things, but building things that work. [LAUGH] Because if they don't, I've literally heard you guys already complain about it from your companies. You know what I mean?

It's a fair argument that why am I using something that they're not supporting properly? So when you build these kind of things, it is incredibly important to have testing or things like that. Because, again, the goal of this is to make changes everywhere, not just one place. And so if it's gonna be able to make changes everywhere, we need to be able to predict that and make sure it works properly.

Cool, so now that we do this, I'm just gonna save this, and let's do this. We'll say const file =, and we'll just get this file like this. Sorry, my thing is in here. Well, look at that. I didn't have to write a Dockerfile. [LAUGH] Yeah, I mean, we're gonna finish it, but that is really it.

[LAUGH] It's taking, again, a bumper, putting it around the developers, and then making a tool that the developers can use reliably, right? And so again, in this case, what we're doing is we're saying, all right, devs, you get to use this, right, and then you use our tool.

That's it, you use our tool. And when you use our tool, You'll get exactly what you expect. So if we go back to here, and then I believe it's build, right, build.json. Didn't do that right. I hate that my history doesn't go to my terminal. Build, that should work.

No, two up. Config, right, not build, okay. Also helps to remember the code you wrote. [LAUGH] There we go, cool.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now