Writing the Dockerfile

[00:00:00]
>> So now, we are actually rendering a Docker file, right? And so the last thing we need to do is we need to make sure that we can actually get it to where we need. So this is a bit of an opinionation, it's up to you if you want it to work this way or not.

[00:00:22]
I'm gonna do it just for sake of time, but you could make the CLI tool actually do this remotely. Clone the repository, make the changes and push it back up. So, another thing you could do is you could write automation weekly to do that. So that if you made changes to things to improve, say build performance, Docker file performance, things like that, then you put this CLI tool in automation.

[00:00:52]
And you tell it what repositories it's supposed to work against, and then it'll clone those repositories, run these commands for you. And now I'm automatically updating configurations you never have to write. And this is something we do at Hippo, where I work. I actually have an additional command to this where I can say this, remote, and then repository basically, if I spell it right, there we go.

[00:01:20]
And then, for example it'd be like example repo, and so what happens is, even if I wanted to, because remember the build.json or with the repository I used to do that. I don't even need to have a configuration locally because it's standardized. These files are in every repository now.

[00:01:42]
And yeah, this is literally what I do a lot at Hippo, and when we were talking about earlier about saving money? Think about having 200 repositories that you have to go in and update every build configuration for every Docker file update for, simply because you don't have to do that anymore with this.

[00:02:06]
You know what I mean? You can simply just automate the whole process if you wanted to. And so yeah, that's another thing, like I said I'm not gonna to get into it today because maybe we can do it on a separate course or a separate class. But how you take this and how you render it is entirely up to you.

[00:02:25]
So for now I'm just gonna render it into the current directory, and we're going to assume that a developer would just be running this in the root of a repository, right? And if we wanted to we can make the developer's life even easier, where we can say you know what?

[00:02:44]
Don't even worry about telling me the path. What we can do is we can say we'll just hard code it, right? Now the reason why I showed it to you, the way of not hard coding it, is because you may want to not have it in a specific path or something like that.

[00:03:00]
However, this is what we actually do at Hippo, we standardize it down to the folder and the location of it. So that if it's not in the place that we expected it just doesn't work. So again, that's totally up to you but it is i something that might be recommended, and so now you can see we don't even need yards really, unless we wanna add other commands and stuff like that to it.

[00:03:24]
For right now, we'll leave it just to show it as a proof of concept. Okay, so now that we've got this Docker file, we just simply need to write it, right? So, write file, yep, write file sync. And then, what do we give it? We give it the path and then the data.

[00:03:44]
So the path in this case is gonna be Dockerfile, and the data will be dockerfile. We'll get rid of this as well. So now, if we run this again, There you go. And now you have a Docker file that you never have to write. [LAUGH] And again, this is a super, super, super, super simple example.

[00:04:17]
Super simple example. So, let's get a little crazy. Why not, right? So what I'm gonna do is I'm also going to add a file for circleci.yml. Because the Docker file's nice, but we're not fully doing it. I guess one thing we could do, here, let's add this really quickly, actually.

[00:04:36]
So let's go back to the Dockerfile because we did forget something. We forgot to do our for loop right of our Dockerfile stuff. So what we need to is, is we need to go back our index. We go back to our index, and we've got the service name and the service type, but what's a better thing that we could pass to this, so that we always guarantee the values that we have in our build.json, get passed down to our template?

[00:05:13]
What could be in these, like what what could we do in this render here, right? Instead of saying like service name, configuration service name, service type, configuration service type, right? What object maybe could we pass directly to it? And it'll always make sure our templates get all of the build configuration variables.

[00:05:37]
So we can pass it, just the configuration data itself, right? Because it's already standardized, and we already know that it's going to have everything that we need in it, right? And so now what we can do is is we can say, all right, tell you what, Dockerfile, you're gonna render as a Docker file, but we're gonna give you all the configuration data.

[00:05:57]
So that if we go to this docker file, now what we can do, sorry, not that one. This one. Now, what we can do is we can still have our service name and our service type, but we can also extend things like our for Dockerfile.PreInstall commands. I believe is how you do that.

[00:06:20]
And then endfor, so then we just do for command in Dockerfile.preinstall commands, and then what we'll do is we'll just say, command, just like that. So now, if we do this, There it is. Now, it doesn't look pretty, [LAUGH] because the templating engine doesn't care about lines. Don't let developers complain over that.

[00:06:57]
Tell him, [LAUGH] tell him you're getting it for free, okay? [LAUGH] I've dealt with that before actually, where devs have been like, why is it got so many lines? It's like, dude it's a templating engine, like it's fine. The computer doesn't care about it. But like I said, going back to what we really care about, it does give us that flexibility that we want.

[00:07:16]
Now if a devs like, okay, I need something else, I can just do copy something, something, right? And then literally, think about this. I don't even have to do anything but update the config file, and then just re-run the command. This tool has saved us so much time and money where I work.

[00:07:47]
Because again, like I said, I don't have to do this anymore. The developers can now do this. They can customize their Docker files the way that they need. And say for example, I kind of hinted at something here without really fully showing it, That's why we call it a pre-install command, right?

[00:08:13]
Because it's before the yarn install. And what do we normally care about before the yarn install? Moving files over that we need to copy, right? Package.json, things like that. This also means that, you know what? Eric, it's great that we have pre-install commands, but I've got to do something after that, too.

[00:08:32]
Cool, done. You know what I mean? Cool. PostInstallCommands. And then we go to our build.json, pre-install, PostInstallCommands. So developers should not really have any problems once you set it up in a way where you're solving the problems that they care about, right? We're not just trying to put in configuration and just let it just get dumped in there for them.

[00:09:26]
What we're saying is, is we know with a Docker file, you're gonna have to do some things. You're gonna have to do a yarn install. You're gonna have to do this. Now, what is one caveat to this? If you could tell me what is one caveat to this Docker file template that is specific to say a language?

[00:09:48]
Could I use this with Go? Well, yeah, no, it's okay. I mean, that's a fair answer and an honest one. And the reality of it is no, I couldn't because it's using a yarn install, right? So if we're agreeing that we're only building node services, and we're only using yarn, right?

[00:10:14]
Then this is a perfectly good way, like you guys could literally use this today. And you probably should. But seriously, what happens if we run into that, right? What happens if it's like, well, it's not a node thing, we do the exact same thing that we've done before, right?

[00:10:34]
Where we say, okay, well, there's a couple of things we can do, right? We could say, well, you know what? We could do that, right? And we could actually say, Dockerfile.InstallCommand, right? So now, if I go back to my build.json, and then we just do install command, right?

[00:10:59]
Now, we don't need multiple of these, so we only need one. And, so here's the thing that's kind of fun. Technically you don't even have to update the DSL with this, because of the way templating engines work if the variable just exists in the configuration, it will become available here, right?

[00:11:22]
However, we wanna make sure that it's actually in our type so that we can use it in the language itself. And so what we would do is, like that's why you notice how pre-install commands is here, but then post-install commands still worked. That's because it's just TypeScript at the end of the day, right?

[00:11:41]
So, if it's still there but it's not typed it's totally fine. And that's a choice, by the way. That could be a choice that makes it quicker for you to adding features if you wanted. So we save this, save this, save this, Delete our Docker file, re-run it, And now we've got our yarn install again, right?

[00:12:11]
Say this is, dude, I deal with this so much, I hate it, I really do. Say a project wasn't set up with yarn it was set up with Node. So what we do is we simply go all right, you know what? That's fine. Cool, you're done, [LAUGH] right?

[00:12:34]
So, it's up to you on how flexible you want to make this tool. However, if you don't wanna ever have to write a configuration file again or something like that, you can totally take this approach to doing it.