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 "Production Environment Demo Part 4" 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:

Kevin concludes his deployment demonstration by finalizing the PostgreSQL connection settings and running the “eb deploy” command to initiate the Elastic Beanstalk deploy script.

Get Unlimited Access Now

Transcript from the "Production Environment Demo Part 4" Lesson

>> [MUSIC]

>> Kevin Whinnery: So we're going to go in here, into our configuration, software configuration, and our RDS connection URL. And we're gonna create a postgreSQL connection string, just like we have been. For local development only, this is the one that we're gonna use in production. User name is gonna be awsuser.awspassword and that's going to be @ the URL for that RDS instance that we just saw.

[00:00:39] And then /todos is going to be the name of the database. We'll hit Apply, and now we should have the necessary environment configuration to actually get this bad boy going. So once this environment update is complete. We're gonna do the pen ultimate step which is the EB deploy.

[00:01:13] So we're ready to do that here in just a minute. With the environment updating, we can't actually kick off the deploy.
>> Kevin Whinnery: And we can see that right now, the application has not been successfully deployed yet, so we can't see anything on our last to be in stock instance.

>> Speaker 2: Couple questions coming in here. Where is the best place and safest place to have elastic bean stock pull in the AWS access key and secret access key?
>> Kevin Whinnery: When you go through the EB and knit process. It's gonna actually save your access key in secret in a doc file like in your home directory.

[00:02:05] And that's generally speaking, where everybody who deploys to [INAUDIBLE] stock on our team keeps it in a .aws directory essentially, in your home directory. So that's where that goes.
>> Speaker 2: And the next question, is it safe to put the DB username and password in an ECT environment variable for production?

>> Kevin Whinnery: If you if you've configured your RDS instance to not accept traffic from the outside as we have like, it's not possible to connect to the database outside of the of the current BPC. In which case, it's not the end of the world to have the connection string as an environment variable.

[00:02:52] But what we typically do is like there's a way to store secure credentials in an S3 bucket and then load them into the system environment. So rather than managing it through the administrative interface directly, you could pull in credential information from an S3 bucket. So that it's not accessible directly through the through the console interface.

[00:03:21] There's different ways to approach that. And this is probably, again because it's not publicly accessible, it's not the end of the world. But probably the best place to do it is in an S3 bucket like in an XML file or JSON file or something like that, that read those in from your application.

[00:03:39] All right, so now our environment is actually in a decent state. So now we've actually npm install, I think we still need to do grunt collect_static to get everything ready to go. Now, we can do an eb deploy,
>> Kevin Whinnery: And that's going to package up, all of the application logic in our directory to a zip file.

[00:04:10] It's gonna create a new application version which we can see through the administrative interface. And ultimately, it's gonna deploy that new version of the application to our instances. And what we saw before, what they're gonna do once the once the application version has been deployed is run these commands that we set up.

[00:04:34] So we have a npm prestart command, which is going to run our migrations against the database. So if there is any available migrations to run, those will get run prior to the application being deployed. And then we have a start command which will run our server process, and start listening for inbound connections on the configured HDP port.

[00:05:01] So if all goes according to plan,
>> Kevin Whinnery: We should have a new version to look at here in a few minutes.
>> Kevin Whinnery: All right, so I'm afraid to look,
>> Kevin Whinnery: But that looks like suspiciously like a to do. And it seems like we are successfully running an application in production has to be instructed you get up there and add some good for you.

[00:05:45] Good looking out. So now we have our RDS instance connected to all of our ACTU instances in the same security group. We have an elastic load balancer, which is what this what this URL is pointing to. It is accepting traffic from the outside world, and it is routing it to all the instances in our elastic beanstalk configuration.

[00:06:10] And our elastic bin stock again is talking back and forth with an RDS database. So that's all it takes to deploy an application on elastic bin stock. But the good part is once you get all of this set up, really all you're gonna be doing going forward is eb deploy.

[00:06:37] You're gonna be is zipping up your application into an archive. You're gonna be deploying a new version, the new version will get installed on all your instances and you can sort of go about your business. There are ways to do a lot of the things that we did manually via API.

[00:07:00] But I wanted to go through kind of all of the different steps, so you could understand hopefully a little better. What it's gonna take to actually get a new environment provisioned on Elastic Beanstalk. Phil asks, do you recommend having a staging environment before going to a production environment on AWS?

[00:07:23] Absolutely, you definitely want to do that. So right now, we only have one environment that we can push to. But it's possible to deploy to multiple environments. So it's definitely good to verify your changes in the stage environment, as we definitely always do prior to go into production.

[00:07:42] The other thing that actually kind of nifty about Elastic Beanstalk is you have the ability to do blue green deploys. So you can deploy your application code to an environment, which is essentially the standby environment. You can validate that everything is good to go in that environment. And then in the administrative interface or via API, you can actually change in this public facing URL, you can swap URLs with another environment.

[00:08:18] So you can with zero down time just convert to another environment that's already been deployed and verified to work with like directly through the interface which is actually pretty rad. We don't actually take advantage of that cuz we don't have access to the console. Because when you work in a large organization, things can be pretty locked down.

[00:08:43] But it's something that we'd like to explore doing cuz it's definitely something that can be done via API as well. Going into the dashboard here, let me just point out a few bits in the administrative interface for Elastic Beanstalk that might be useful. With all of your applications, there's multiple potential versions of the application that could be deployed.

[00:09:13] So if I'm at this level looking at todomvc-plusplus application. I can see all the environments that are running this application, and I can also see all the application versions. So this is the current version of the application that's deployed to production. So you can see, it's currently deployed to this environment.

[00:09:37] And I can deploy past versions of the application. This is how you would do a rollback like if something some stuff hit the fan. You could roll back to a previous deployed version of the of the application. So there's a few things you can do here in the environment configuration, there's also a few bits there worth calling out.

[00:10:07] The log interface, you can actually view the last 100 lines of the logs directly within the administrative interface. But we also have this eb logs oops, eb logs command that we can run from the command line interface. Which will give us the last 100 lines of a couple of different logs.

[00:10:31] It will give us the from our no JS application and it'll also give us like the logs from the deployment commands that are happening on our ESTU instances. So here, we can see the output of our var migrations.
>> Kevin Whinnery: And then we start to see the Morgan logging that you guys were nice enough to add into our application earlier this morning.

[00:11:12] So you can retrieve the logs in that way. The other bits worth showing off in the scaling configuration. This is where you can start to toy with the settings for your application. We can sort of mandate that there's never gonna be fewer than two instances, two EC2 instances running the application at any given time.

[00:11:36] We can put an upper bound on the number of instances that can be running the app, can configure different availability zones. And we can also configure different scaling triggers. So we can say that when the network bandwidth reaches a certain level that is the trigger point at which we can spin up another another instance.

[00:11:59] So there's a lot a lot of capability that we have there. And then on the instances themselves, this is where you can actually configure the type of EC2 instance that will be running your code. The default is a t2 micro, which is pretty small, it has like one virtual core and 512 megs of memory I think and it kind of goes goes up from there.

[00:12:30] So you can configure the actual machines that are running your application based on your performance requirements.
>> Kevin Whinnery: We've already kind of looked into the software configuration which is another bit. We're also look at some of the health check features that are present here tomorrow, and we talk about like monitoring this application environment.

[00:12:57] There's a few other that you can you can mess with for updates and deployments by default. A third of your fleet of instances whatever that happens to be. If it's just three, it'll be just one of them. But essentially, when you're doing a deployment, that's how many of those instances will be taken out of the load balancer to perform your application update at a time.

[00:13:24] And once that one instance has been updated, it's gonna be put back in the load balancer and the other instances will be taken out. And that instance will start accepting the traffic from the load balancer. And you can configure like how much of your fleet you wanna take out and update and put back in to the load balancer there.

>> Kevin Whinnery: All right, so that was a tremendous pile of stuff to do. But for anyone who wants to attempt it, I will take you through the steps. The documentation or the place to start, that I put in the chat was starting with the EB COI. Then again, I think actually bring up the 10,000 foot view of this process here.

>> Kevin Whinnery: Within a region, you'll create a user, you'll download those user's credentials. You're going to create an Elastic Beanstalk environment from the command line. You'll create an RDS instance through the administrative interface. And you'll configure a security group to allow incoming connections. So there's a few pieces of that process that are a little bit patsy.

[00:14:42] So I'm happy to help you through any of those individual pieces if you'd like to give it a shot yourself. But again, I think the benefit here is that this is being recorded and all of you can watch that ordeal again at another time when you're actually going through this and clicking the buttons.

[00:15:03] So there's definitely a lot of pieces to set up. But hopefully that gives you a sense of what the moving parts are during the process.