Introducing DevOps for Developers

Generating a Dockerfile

Erik Reinert

Erik Reinert

Introducing DevOps for Developers

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

The "Generating 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 a dockerfile containing ENV variables for service names and service types. Updating the build.json to allow for more overrides in the dockerfile is also covered in this segment.


Transcript from the "Generating a Dockerfile" Lesson

>> So let's talk about the next thing, we'll start with the Dockerfile, right? So we said that we want our CLI tool to be able to take the build.json, right? And then be able to have a service name and a service type so that it can generate a Docker file from it, okay?

So what we should probably do is we should probably create a directory. And in this directory, we will create a folder called template, or templates, one of the two, whatever you care about. And in here, we're gonna create a file called a Dockerfile, right? And we'll just do some basic stuff, we'll say FROM alpine latest, right?

And then maybe for right now, just to make it simple, we'll give it an ENV, and it will say service name equals or service name like this. But what we're gonna do, and here's where the magic starts to happen here, we're gonna say SERVICE_NAME like this. And we're gonna do this.

Can anyone tell me what that is? So think about it like this, say you deploy tons of services to the cloud, right? And you want a way of being able to know from a logging perspective, what the service name is, what version it is, all those kind of things, right?

This is a step towards that direction, where now that we have generation and flexibility around creating these files, we can use this literally anywhere. And so for example, we can say ENV SERVICE NAME, ENV SERVICE TYPE. Service type, and then we do service type. So let's do this as well, we'll say service name like this and service type.

Now we're even following that same convention. And then, we could say like run, Anything really at this point, doesn't really matter slash bin bash, right, really doesn't matter. Cool, so this is, again, really all I wanna show you, but I'm gonna show you one other thing as well which is, Say this isn't enough.

A lot of times, there are circumstances where you'll find yourself needing to add a copy command, right, or add a run command, or something like that, right? And what I've discovered is super helpful, is instead of trying to add it to this file, we simply add it to the configuration, right?

So let's go back to our build.json for a second. Let's say we wanna make it so that we can override more lines in the Dockerfile, right? What we can do is we can simply, again, a developer comes up to us and says, hey, I've gotta add a .gitignore, and it's not in your thing, how do I do this?

Well, we can literally do this. Right? This makes it so that developers don't touch Dockerfiles. [LAUGH] I have blown so many developers' minds with them finding out that they can just add it to our configuration, and they never have to write a single line of code. This is the kind of power that this tool represents, right?

Service directory gave us the ability of automating our services, having good standards around them, making it easy for our developers to copy and paste the infrastructure they need, right? But that's not it. Developers also have build configuration files, they have other things that they need. And guess what, I don't wanna do that either.

[LAUGH] And so in that circumstance, we can do things like what you see here where we can say, we could even do the same thing to the circle CI file if we wanted to. We could say CircleCI, TestCommand. Maybe your specific service does yarn test, whatever, instead of our normal standard yarn command, right?

So this is a prime example of what we can do with really just domain-specific languages in general. When we tell developers how they talk or how they work with our stuff, right, they've always got those blockers, or they've always got those bumpers that they're gonna hit. So I'm gonna delete the CircleCI one for now, but I am gonna do the pre-install commands one because I think this is a good example.

Let's show it how it's wired up, right? So, I'm gonna go back to our index.js, and I'm gonna say Dockerfile. Now I'm gonna actually go back, because I wanna type this too, for say BuildJsonDockerfile. And so now, we'll say, BuildJsonDockerfile, and look how easy it is to add to the DSL.

Bam, now I have whatever they need from their configuration, and I can easily use it in templates if I need to. So this is something else that's really powerful about building this type of tool, is you can add to it. And you can keep adding to it. There should be nothing [LAUGH] that a developer needs that you can't put into a domain-specific language like this, and simply tell them, okay, you need to be able to run a command before the pre-install, cool, here's the configuration for you, don't touch the Dockerfile.


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