Zero to Production Node.js on Amazon Web Services Exercise 4: Deploying the Application Part 2

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

[00:00:00]
>> [MUSIC]

[00:00:03]
>> Kevin Whinnery: So, it's possible to go to create environments through the console directly, but what we did during our exercise, was actually create it from the command line using the elastic be in stock CLI. So we cloned our application, we entered that application and then we started off,
>> Kevin Whinnery: With the eb init.

[00:00:31] And eb init is what took us through choosing an AWS region to run our application in. It's where we created an environment or excuse me, it's where we sort of configure our credentials for our AWS user that we used to use the Elastic Beanstalk command line interface.
>> Kevin Whinnery: And then, after we ran eb init.

[00:01:04]
>> Speaker 2: When you're going through that and ask for the AWS access id, where do you get that from
>> Kevin Whinnery: When you downloaded your credentials before in the console when you created the user. That download will have the cs eb init with an access key and a secret value.

[00:01:20]
>> Speaker 2: Where does that get stored if you had a user already created.
>> Kevin Whinnery: If you had a user already created but you didn't download the credentials you need to regenerate credentials for the user and whatever credentials they had previously would no longer reality.
>> Speaker 2: So- And you can do that from the user.

[00:01:41]
>> Kevin Whinnery: Yes, you can. So for individual users here's, I'll do a different one. So here's the on the user that a user I created for an earlier test. So here is their credentials. You can see the access key again but the secret, you'll never see again. But what you can do is you can create a new access key and you can download those credentials or you can click on this link and you can actually show them in the browser.

[00:02:18] So you have a chance to create a new set of keys as well. Is that kinda
>> Speaker 2: So, you do create an access skin, then you download the credentials there. And then, that file is the one that you put in when you do an eb init.
>> Kevin Whinnery: You don't put it in the file, but you use the access key in the secret strings from that file that you downloaded.

[00:02:44] So here, I'll just download this and I'll show you what I mean. So I just created these access keys. And then, that's gonna be downloaded in a CSV
>> Kevin Whinnery: So if I open that CSV with a text editor, it's got my username, my access key and my secret.

[00:03:09] And those are the values that I will plug in during the eb init.
>> Kevin Whinnery: That kind of makes sense?
>> Kevin Whinnery: So the eb init is where we plug in our AWS credentials and we sort of initialize our application. And then eb create, is where we create an actual environment with EC2 instances in it, that we can actually use to run our code.

[00:03:54] And that took a very long time but once it was created, we ended up with this. When we went to ask the Beanstalk, now all of the sudden, we have this environment. And the way we did it before, it was under configured so it wasn't okay right away.

[00:04:12] But we have this environment which is actually running EC2 instances which have our code. So on the configuration side, what we needed to do is go into our instance configuration and check out what EC2 security group. The EC2 instance is managed by Elastic Beanstalk or a member of.

[00:04:38] And that is a value that we had to use a few other places, if you remember. The first was when we created a new RDS instance, which is what we did next. So [INAUDIBLE] RDS
>> Kevin Whinnery: And we created an instance,
>> Kevin Whinnery: for PostgreSQL, and during the configuration process we added that RDS instance to the same security group that are Elastic Beanstalk EC2 instances are a part of.

[00:05:18] So that essentially enables them to communicate with one another. Once we created that RDS instance, put it in the same security group. The other step we needed to do was to go into the EC2 configuration,
>> Kevin Whinnery: Go down to Security Groups,
>> Kevin Whinnery: And then select, I believe it was,

[00:05:50]
>> Kevin Whinnery: Keep my mouse over that.
>> Kevin Whinnery: We selected the same security group in this administrative interface. And for under this inbound tab, we needed to add another configuration for Postgres on port five, four, three, two. That would allow inbound connections to four members of this security group.
>> Speaker 2: So the typical port for Postgres?

[00:06:26]
>> Kevin Whinnery: What's that?
>> Speaker 2: Is that is a typical port that's used for?
>> Kevin Whinnery: Yeah. Five, four, three, two, is the sort of default.
>> Speaker 2: Standard.
>> Kevin Whinnery: Yeah.