Configuration

[00:00:00]
>> Josh Long: Okay. And then finally, as we kind of wind down this section here, the last thing I want to talk to you about is configuration. I've been making changes to this program using application properties. Yeah, I can change things like the port on which this runs. Like I can do 8081.

[00:00:17]
Or if I want it to run on random port, I can choose zero, right? It'll just pick a random unused port on the operating system. That's an environment variable that could be. I'm sorry, that's a property file, a property value. If I go to the command line and I do /maven spring-boot:run.

[00:00:33]
Actually here, let me just do maven package. So I'll have a compiled jar, okay? Now I go to the target directory. Du -ds is, there's a jar here, right? I can do Java minus jar Java. Actually, can I do this one? I think I can. No, java- jar, that, okay?

[00:00:51]
That's the application up and running on which port its random port. But now let's say I wanna override that. Well, I can say --, or sorry, Dserver.port=8082, okay? So now you can see it started up on port 8082. I can also do environment variables. I can say serverport equals 8083 and we can keep that one there and we'll see there's 8082 and environment variable.

[00:01:22]
Get rid of this run that. I can see it's on Port 8083. So every property that you see me put in here can be made into an environment variable. So when I specify spring data source, secret or password, obviously you're not going to do that in production. You're not going to check in the source code to your production Oracle database or whatever into your source code.

[00:01:46]
What you do is you'd say SPRING_DATASOURCE. At the very least, you do this, right? DATASOURCE_PASSWORD=foo, right? And then run the process, okay? So you can pass in configurate, you can override the default configuration. This is the 12 factor app style deployments, right? You don't have configuration that changes from one environment to another in the build itself.

[00:02:09]
It should be externalizable. And finally, I would definitely recommend using something like. Do you use a dir env? Anybody here use something like dir env? Direnv is another really handy tool for configuration, right? So let me see, if I do this here. If I create a file in the root of this folder, touch _envrc, right, okay.

[00:02:40]
I'm going to open this up now, echo hello frontendmasters. Now I'm going to do DRM allow. So if I go back to here and I go to demo, it says hello friend and masters. I can even export environment variables. So export foo equals bar. So now I go back up echo foo, nothing CD into this and it's asking me do I want to run this file because it's new drmvalao.

[00:03:15]
Great. Now what is foo? If I echo foo. So why does that matter? Well, it means you can put environment variables in this directory. Somebody cd's into this directory, now they have the correct version of Java because you have SDK main rc. You can also have the correct environment variables, right?

[00:03:35]
Now, should you put your AWS S3 cluster credentials in this? Definitely not, right? Which brings us back around to one more thing. Use your password manager. Most of them have clis. I don't know what your organization uses, but what I find to be very effective is to have like if you're using one pass or LastPass or I use bitwarden, which I love, you can use whatever you want.

[00:03:59]
The point is they all have clis, even Apple, there's a third party. I'm not sure how good it is, don't quote me, but there's an Apple passwords CLI now that somebody else built that you can use to talk to the password manager. That's new in Mac OS 15.4 or whatever it was.

[00:04:13]
And so you can use that to, given the name of a key, pull down the value so it'll prompt you to authenticate in the shell. You log into your password manager, in effect in the console, and then you can actually use the token that it gives you back to make requests against the API for the password manager.

[00:04:31]
So what would you put in here? Well, imagine somebody CDs into this directory. Now you have environment variables that are in session or in scope, but you need to get certain items. So the way it works in Bitwarden is use BW getitem and then the name of the item it'll ask you to authenticate.

[00:04:51]
So you authenticate, then it'll get the item and then foo will be equal to that value. So now, as long as everybody's using 1Password or Bitwarden or whatever, cuz I showed you Docker, right? Docker is great for things you can run locally. But S3, you've got a development S3 cluster or development S3 bucket, I mean, or buckets, right?

[00:05:13]
You don't want to store that in the source code, so you store that in the Password manager for your group and then each of you has access. You can share that secret with everybody. The admin or the team leader, whatever can do that. Now, when they CD into this directory, DRMV runs and it automatically tries to set up these environment variables that has the S3 credential for you by talking to the password manager.

[00:05:34]
Now in this shell, that is when you run idea pom.xml, right? Because now, so if I close this out, I command qt intellij, right? It's gone, there's no room intellij now. So now I'm going to go to demo DRM allow. Okay, so now it's asking me to get an item.

[00:05:52]
It's going to fail because I don't have a. I didn't ask it to get anything. But echo foo is still there, right? Whoops, I forgot to set this back to something usable. Bar CD demo. There you go. Echo foo And I open this up again, Pom xml and I'm opening it up in the same shell where I set that environment variable.

[00:06:20]
So now in my Java code, what if I need to depend on that value? Well, I can inject it. I can get access to that value like so, right, foo. Okay, so now I restart this. I've injected the environment variable there. Go to the console. Hi, what did I call it?

[00:06:50]
I did call it hi, right? It's port 8083. Right. We changed that. What's the port? It's random. That's zero by default. Okay, so there you go. You can see I was able to access and reference those environment variables from within my spring boot application. You can also reference them from within this property file.

[00:07:14]
So for example, maybe the secret, maybe the password for your database is whatever is in the environment variable called foo. You can just reference it like that. So far, so good. So this is all stuff, there's no reason anybody should ever store credentials in source code unless it's like SQLite on the local machine shared by nobody.