Building for Production with GraalVM

[00:00:00]
>> Josh Long: So with actuator on the class path, and now you've got a kind of a sense of what you're doing with that. You're making your application production worthy. Because remember, in production, nobody can hear your application scream, okay? It's very important to give it the ability to speak.

[00:00:12]
The actuator is how you do that. And that's been there since day zero, right? We introduced spring boot 0.4 back in 2013. We had this. This was part and parcel of the spring boot experience, is production worthiness out of the box, okay, so now what? Let's get this thing to production.

[00:00:29]
And here we have a couple of different things you might want to do. Maybe you wanna build a native image, right? We talked about that yesterday. So maven skip tests. P Native, native colon compile. Okay, you can do that. That'll build a Native GraalVM Image that you can run in your environment.

[00:00:47]
We have a native binary at this point, right? At that point you're going to try and run it. You go to the target directory, you choose. I'm going to choose E2E because that's what I named it. And it's going to fail, right? So the reason it's going to fail well in my case is because the port's already being used by the same existing process in Java.

[00:01:02]
But it's going to fail again because it doesn't have any credentials for the database. The reason it doesn't have those credentials is because we are using the Docker compose support, which automatically prescribes the username, password and host and port for the service when we start up the application in development mode.

[00:01:20]
But we're not in development mode. We have a production binary now. So how do we run this thing in production? Well, you need to give it configuration. You could do a couple things here, right? If I take spring, I can do this the old-fashioned way, spring.datasource.password=secret, right? Spring.username is myuser, right?

[00:01:41]
And then spring.datasource.url is jdbc:postgresql://localhost/mydatabase, okay? So this is the configuration. I'm gonna put that in a separate file here in the target directory. It's called application properties. So let me open up this one. I'm just pasting it there. In the target directory I've got a separate property file called application.properties, okay?

[00:02:07]
That's gonna be added to the properties that are already in the native code, so let's try that. So the next problem we're going to run. If we'd run that though, before we do that is this is not running publicly. It's not exposed over the port. So I need to restart my Docker image, right?

[00:02:22]
Go to the target and then docker compose up, manually, okay, cd target, and now there you go. So now the application's up and running. It connected to the SQL database, right? And of course, it's running in a tenth of a second with much less RAM. So the key bit there was that we are no longer able to rely on the Docker Compose support in the production environment.

[00:02:47]
So you have to manually specify how to connect, right? I did that by putting properties in a property file. The other thing you could have done, I could have done this. I could have gotten rid of that and just done. Spring data source username equals secret, right? Or sorry, myuser, right, or better, just to export that, export the PASSWORD equals this, okay?

[00:03:17]
And then the URL=jdbc:postgresql://localhost/mydatabase, yeah? So now I do this again, same thing. It draws the config from the environment variables or from the property files, external, outside of the binary, right? So you can deploy the binary from one environment to another, development Q&A, sit, whatever. And it's the same binary, but you have externalized properties.