This course has been updated! We now recommend you take the AWS for Front-End Engineers (ft. S3, Cloudfront & Route 53) course.

Check out a free preview of the full Zero to Production Node.js on Amazon Web Services course:
The "Exercise 4: Deploying the Application Part 3" Lesson is part of the full, Zero to Production Node.js on Amazon Web Services course featured in this preview video. Here's what you'd learn in this lesson:

In the final part of the exercise 4 walkthrough, Kevin completes the Elastic Beanstalk configuration by creating a virtual directory for the static assets and adds the environment properties. Finally, Kevin runs the “eb deploy” command to deploy the application and views it running on the production server.

Get Unlimited Access Now

Transcript from the "Exercise 4: Deploying the Application Part 3" Lesson

>> [MUSIC]

>> Speaker 1: And then, once that security group MumboJumbo was configured, then at that point, we pretty much had everything we needed to actually deploy the application, so we had to complete the configuration of our software. So if we go back to our actual Elastic Beanstalk application and configuration, we changed our software configuration.

[00:00:31] We changed the version of Node that we were running on our instances to 622. We created a virtual directory for our static assets. So the NGINX proxy server on each of our instances will serve static assets rather than Node doing it. The express static server is much slower than NGINX would be.

[00:00:55] So we can figure that directory, so engine X will serve up our JavaScript and CSS, and images and what have you. And then, we created three environment properties. We set the NODE_ ENV to production. We set the NPM_CONFIG_PRODUCTION value to true, so that when Elastic Beanstalk does an NPM install on our application it only installs the dependencies that are necessary for production.

[00:01:24] And then we also created a Postgres connection URL, which we are here storing as a as a system environment variable that we created through the interface. But an alternate way that you could do that is to store this connection string somewhere else outside of the administrative interface. You could store it in S3 bucket or something of that nature.

[00:01:53] Because this database can't accept connections from the public Internet, it's like not the end of the world necessarily. But the proper way to do this with any secret value like this would be to have it outside of the administrative interface. For our purposes, it's a decent solution. So after that was configured,

>> Speaker 1: Bruce asked does anyone know what the needed environment properties are for the to do MVC config screen? That would be these three. The environment variables that you need in production are the Node_ENV set to production, the NPM_CONFIG_PRODUCTION flag set to true, and then a RDS_CONNECTION_URL, which is the database connection string for the actual post res database.

[00:02:55] And that URL string, the URL string for RDS, comes from the configuration for the RDS instance that we created. So if we go to our instances over here,
>> Speaker 1: Here's the one that we created.
>> Speaker 1: If we inspect its properties, we can see it's what's labeled as the a Writer Endpoint over here and that is essentially the internal address of that particular database.

[00:03:35] And when we created the database, we created a user which we called AWS user. So we included those credentials in the form that Postgres://username:password@ this URL :5432 a this URL port 5432/ToDos, which is the name of the database that we need it to connect to. So that is the full genesis of that RDS connection string.

>> Speaker 2: So if you create an instance like that and you're in development and you just let it sit for a while, does it just go away for a month or something of inactivity or does it stay there forever?
>> Speaker 1: It'll stay there forever. So the default configuration is that you can only ever have one instance running.

[00:04:39] So we can take a look at that.
>> Speaker 1: So that is actually a scaling configuration. So if we go in here for Scaling,
>> Speaker 1: We have the minimum instance count of one and then we also have a maximum of four configured right now.
>> Speaker 1: Yeah I know, I'm too excited.

[00:05:19] I can't sit down with this much raw AWS action going on.
>> Speaker 1: So yeah, lots of yak shaving at the beginning. When you get past that,
>> Speaker 1: As I said, we're really in the situation of building your application, zipping it up, and deploying it with eb deploy. There's different options you can do.

[00:05:53] You can deploy applications to different environments. There's lots of flexibility that you have with the platform. But in terms of the workflow, it improves significantly from here on out.
>> Speaker 1: So was that helpful to go through one more time? Okay.
>> Speaker 1: So yeah, there we have it. I think I have successfully made sure that like 50% of you will run screaming for tomorrow with dropping this AWS bomb on you today.

[00:06:47] But tomorrow, now that we have this bad boy up in production, we're gonna be focusing mostly on more of the application stack. We'll be looking at the front end tool chain. We'll be learning a little bit about Vue JS and how we implement a rich front end with view.

[00:07:08] We'll be adding some features. We might have successfully got our back end application working to set that completed flag, but we still have to do some work in the user interface to make that happen. So we'll be doing some work with Vue JS tomorrow. Well to be talking a little bit about monitoring production environment.

[00:07:29] We'll add some modest real time features, a socket IO, to our to do application, so we can see how that plays out in our production environment as well. Nothing too crazy, but we will be adding a little bit of real time spice and we'll be looking at how to implement web analytics.

[00:07:52] Because we're using Node and Browserify, we have kind of a nice way to implement Google Analytics on our in our application, both for custom event tracking and for basic stuff like page views. So we'll implement universal analytics in the front end as well. So yeah, I think this is definitely the hardest part.

[00:08:17] So if you wanna keep banging on it, we definitely still have some time and I'm happy to go through any of those steps again for anybody. Question if there is going to be a merge for the exercise three solution and there definitely will be. I'll push out my local changes for the database piece in the migration.

[00:08:47] We have a question if we can work along with our local environment tomorrow. You absolutely can. You don't have to use the production environment, if you if you don't want to tomorrow. You can just use your local development environment.
>> Speaker 2: All right, with that, I think I'm gonna un-mic, but I will stay on the chat and stay in the room for anybody that wants to keep on trucking.

[00:09:18] If you have questions on the deployment stuff or any of the Node stuff that we covered today, I'd be happy to answer any questions that you have or talk about specific scenarios that you're interested in. I know that was a lot. I hope it was helpful. Once you kind of get through all this stuff, as we'll actually see tomorrow, this environment can actually take a decent beating, much more than you would think out of compute resources of this size.

[00:09:48] So will beat up on it a little bit tomorrow and see how that works as well.