This course has been updated! We now recommend you take the Full Stack for Front-End Engineers, v2 course.
Transcript from the "Course wrap-up" Lesson
>> Jem: Yeah, that's it. Everybody now understands how the Internet works. You have set up a domain, you've pointed to a server, you set up that server, you set up a node server. You built a deploy system so that you can push things to it from your Git repo; if you want to make your own repo and just that node app will stay up forever.
[00:00:20] And it's just easier than to keep rebuilding it every single time. Good work everybody. You did it.
>> Speaker 2: So aren't the standards around HDV2 and like performance and all this kind of stuff. Isn't that really evolving right now, because I feel like I don't, I hear like conflicting things like bundling your scripts.
[00:00:41] You don't need to do that anymore or just different performance stuff. How do you start about that?
>> Jem: So let me find, I'll show a demo which will probably help a little bit better. It was a, what was it called? 2 demo, Akamai. So Akamai has an excellent example of why we use HTTP2.
[00:01:12] So the power of HTTP2 is that it can process requests kind of in parallel. HTTP1 does one, then one, then one, then one. HTTP2 does it in parallel. So the benefit of that is, it's actually faster not to bundle all your scripts together into one file. Because in that case, it's only one connection.
[00:01:31] Whereas we serve, say, four different scripts, HTTP2 can pull them all in at the same time. But as Mark was saying, there is an overhead to doing that. It costs a certain amount of processing time and RAM to make all these requests. So with HTTP2, you don't necessarily wanna bundle it all together, but you don't wanna have 50 different bundles.
[00:01:51] That's gonna be very expensive.
>> Speaker 3: How would you be using HTTP2 versus HTTP1? Would all the websites using HTTP2 start with HTTP2?
>> Jem: No, great question, the easiest way to look at it, is just open it up in Chrome Inspector. And we look at the Network tab, just refresh.
>> Jem: Scroll, I don't know why it just killed this, close the console.
>> Jem: That's weird, I don't know why it keeps closing. But in protocol it'll say HTTP2, and it lets you know that you're on a HTTP2 connection. Let's see if I can look at my own server configuration, I wanna say I have HTTP2 set up, maybe.
>> Speaker 3: So now as our next question, is there something that we can do to make sure that we're using an HTTP2 connection versus HTTP1?
>> Jem: So we can. In,
>> Jem: I guess I didn't do it for my own website yet. But in the server config for your NGINX instead of using SSL, it's a little different.
[00:03:08] But you just put HTTP2 and it's now HTTP2.
>> Speaker 3: Just automatically?
>> Jem: That's it. The only issue is at this point you need to make sure node is using HTTP2 as well. Cuz remember, we're just tunneling a connection through NGINX to node. So node needs to use HTTP2, that's why I didn't want to go down that path, cuz it's a little more involved.
[00:03:26] Just like setting up an SSL certificate is a little more involved as well, to do it properly. And that's more of an advanced class. But hopefully now you guys have the tools to go out and do this yourselves if you wanted to. And I'm always around by email if you run into issues.
>> Speaker 3: In the index HTML, could you just throw in a link to pull in the style sheet? Because I keep getting a 404 when I check the network tab, and I wasn't sure if that was something that maybe the app.js needs to serve up, or NGINX was.
>> Jem: That is a good point, let me.
[00:04:00] So yeah, just point to /static. CSS, and that's going to point to your disk folder now, so it should serve properly. Good catch everybody.
>> Jem: And in our app, I'll make a few minor changes. In our app.json, we need to add forever stopall. Before we start the app.
[00:04:25] So we're just gonna make sure all of our forever processes before are killed. And I will post this up later to GitHub just so everybody has a complete working demo. But for now, just add in your deploy scripts, just add forever stopall, ampersand ampersand, the rest of it.
[00:04:42] Forever start app.js, etc, etc.
>> Speaker 2: And the app.js file.
>> Jem: Exactly. And one more edit.
>> Jem: In our app.js file, we just need to add this line in there. App use /static. And we're gonna serve from our dist folder.
>> Jem: So now we can take a look at our forever processes, just to make sure we don't make the same mistakes.
[00:05:11] So if we say forever lists, it'll tell us everything that's running. And there should only be one thing running, and that's your current node app. So, we run, npm run deploy, now. It's gonna stop the current process and then restart all of our processes. Which in this case is only one.
[00:05:29] See, npm run deploy. And we're just gonna verify with forever list. What's up and running? And, only one thing.
>> Speaker 2: Then, you say you have many servers, would you run the deployment from your laptop involving some SSH to deploy all different servers?
>> Jem: No, If I had many servers, there are tools that are much better for deploying multiple servers.
[00:05:54] Ansable, Chef, Puppet, are all much better tools for doing multiple servers. And actually bringing servers online at the same time, and then taking them offline, things like that. But if you're only doing one server at a time, it's fine to SSH in. There's a tool called polysh, which means I can SSH into multiple servers at the same time.
[00:06:15] And it'll actually copy my commands to every single server, which actually, it's a pretty fun tool. Let me see if I have it installed. If I don't, I'm not gonna install it. Yeah, I don't have it installed. But polysh, if you have only three servers, you can polysh and then edit every single file simultaneously.
[00:06:32] It's pretty fun to do.
>> Speaker 2: Another question, so with what you've shown, you can serve multiple websites on your NGINX server without putting them as sub domains.
>> Jem: Right.
>> Speaker 2: Okay. You wanna just maybe explain?
>> Jem: Yeah, sorry, [LAUGH] whoever asked that was correct. So let's see if there is, take a look at my other configuration.
[00:06:59] So this is my jemyoung.com server configuration. Don't try to pull it up too much, cuz it's fairly complicated. You can see I'm, NGINX has built in proxying, things like that, so it can instantaneously serve things rather than hitting an actual server. So in my case I'm using a Python server instead of a node server.
[00:07:17] But the server name is important. So jemyoung.com and www.jemyoung.com means that all requests to this particular IP are gonna hit this server block because NGINX is listening for this particular domain name. But If we scroll down a bit. Let me see if I can find modblog.
>> Jem: Port 80, I redirect.
[00:07:44] Yes, so here I have an entirely different server in the same index integration blog. This time it's listening for blog.jemyoung.com, and in this case, it's going to redirect to an SSL version, but it's gonna redirect to a node server. So I'm running a Python server and a node server.
[00:08:04] On the same, in the same Nginx configuration. You actually run probably infinite, maybe not infinite, but you can run many, many servers in one.
>> Jem: Yeah, close enough. You can run many, many types of servers in one Nginx configuration. Generally not recommended, but it's my server, so I don't necessarily follow best practices.
[00:08:23] But you generally for every server you want a different Nginx configuration. It just makes it easier to reason it out. But, great questions.
>> Speaker 2: Can you give a quick overview of the how and why of HTTPS?
>> Jem: Yes, I wish we had time today to put that in, but that's pretty advanced, so.
[00:08:41] Remember we talked about DNS, how if someone changes the IP address of, let's say, jem.party to something else, how would you know it's changed? Cuz your server doesn't show anything. It still shows jem.party. Well, HTTPS is a way of authenticating who I am to the browser. So, in.
>> Jem: Let me just scroll up a bit.
>> Jem: So, on jemyoung.com, I'm listing on port 443. 443 is the HTTPS server. Non-HTTPS is port 80. So, on this one, I'm listing HTTPS, I have a bunch of cyphers, don't worry about any of this other stuff, the keys. But just know that you're essentially authenticating who you are.
[00:09:25] Think of, what's a good way of putting it.
>> Jem: The best way of putting it is there's something called a certificate of authority. A certificate of authority says. It's kinda like the DMV. You go to the DMV to get a license. They say, well how do I know you're actually Jem Young?
[00:09:45] You say, well I've got these papers that show that I am who I say I am. They say, okay. They issue me a drivers license. So that's essentially what a certificate of authority is. Think of it like the DMV. I do a bunch of handshakes, I send a request to a certificate authority, and just says, I am who I say I am, I own this domain.
[00:10:03] So I can handshake every time, and when someone says, is this jemyoung.com? I just show them my driver's licence, it says yes, this is, you are where you say you are. And that's kind of the simple way of looking at HTTPS. And the why? Well, we learned DNS earlier, we learned it's important to be where you say you are.
[00:10:23] Yeah. That's kind of the how and why. We can save the how for probably a more advanced class, it's a little bit more involved. But there's thing that's called acme-tin. It's probably the script I use for using, it's a wrapper on top of the Let's Encrypt. So Let's Encrypt lets you make a free HTTPS certificate.
[00:10:43] And acme-tiny's just a Python wrapper on top of that. And it's a little bit of a setup, but it's worth it cuz you now you have a nice lock icon. So, if I didn't expire, yeah, I have a nice encrypted connection. Another benefit of HTTPS is that everything's secure.
[00:11:04] So everything I send to the server, let's say I was making a bunch of post requests, those are all encrypted using CLS, now. Actually, AES cipher. Yeah so it uses a, I'm sorry. Make that.
>> Jem: Much bigger. Max.
>> Jem: Let's take a look at the certificates. That's not very helpful, but we see, I can't zoom in on this window unfortunately, this is OS level.
[00:11:41] But Let's Encrypt is the authority that says I own jemyoung.com and this IP address is correct. And the bonus part is again, just like an SSH tunnel, everything that I send down the wire is encrypted. So, if someone's sniffing your traffic, which is pretty easy to do. Let's say Mark wants to go back to his hacker days and sniff all your credentials.
[00:12:02] Well, he can't do that with HTTPS because it's all encrypted using an AES cipher, which is a very complex cipher, to encrypt your code. And then, when it hits my server, because I have the key, I can decrypt all that traffic, and I'm the only one in the world that can decrypt that.
[00:12:16] Now, is HTTPS invulnerable to attacks? Well, no. Again, if someone really wants to get your code, they're gonna get to it. Say, the NSA, or something like that, but, for most commercial applications, HTTPS is pretty secure. And you definitely, definitely never shop on a website or put your credentials in to a site that is not HTTPS encrypted.
[00:12:36] Cuz that just means your ISP, the person that runs your router, your neighbor downstairs, they can sniff your traffic and just pull out your credentials cuz it's all in plaintext, yeah?
>> Speaker 3: Yeah, there is a really interesting project before each feedback. HTTPS was like mainstream. Or I should say it should've been mainstream, but people weren't switching over.
[00:13:00] And it was like a plugin called Firesheep. Do you remember that?
>> Jem: Yes. Yeah.
>> Speaker 3: And so people would just install Firesheep. And then everybody in the room at a conference would be like logging into Facebook without HTTPS. And they would just be like, got your credentials, got your code key, got your, and all of this stuff.
[00:13:16] And it was just like yeah, so never do anything.
>> Jem: Let's see if I can.
>> Speaker 3: Outside of HTTPS. I mean I could.
>> Jem: Let's see if I can sniff my traffic. Charles is a, it's a proxy for modifying HTTP requests. I use it at work all the time.
[00:13:35] And, yes. That is what an encrypted HTTPS connection looks like. It's just gibberish. Because it's all encrypted. Now, let's see if I can find an unencrypted connection. Somewhere in here, let's see if we go to maybe jem.party, that might show up.
>> Jem: Yeah, and see the entire response and request is unencrypted, and I can read.
>> Speaker 3: Yeah, so if you send your password, or you send your credit card over the wire and-
>> Jem: Exactly.
>> Speaker 3: You don't have HTTPS, it's just gonna look like that.
>> Jem: Exactly.
>> Speaker 3: And anybody who is sniffing, and the thing is a lot of the times, they're just logging the traffic.
[00:14:17] So your passwords or stuff are just sitting in some random coffee shop's log or whatever.
>> Jem: It's [LAUGH] the equivalent of yelling across the Internet. Saying, hey my login's Jem123. If you don't use HTTPS. So I won't say it's super trivial to set up. But at this level and the way everybody's kind of flown through this class, everybody has the capabilities now to set up HTTPS on their own.
[00:14:43] There are many, many tutorials. I recommend Let's Encrypt because it's free, but I'm pretty sure Namesheep has their own proprietary certificate authority.
>> Speaker 3: It's getting easier.
>> Speaker 2: Let's Encrypt's awesome.
>> Speaker 3: With more and more services and more and more adoption to get set up.
>> Jem: Yeah, quick note on certificate authorities.
[00:15:07] They have to be trusted. So again, this requires Let's Encrypt being entrusted that, yeah, this company is valid. There have been many instances, specifically some Chinese certificate authorities that have been, their credentials have been revoked by the internet. Because they're saying, yeah, you're on google.com. Wink. And again, it's just a trust system.
[00:15:29] If you can't trust the certificate authority, you can't trust the site you're on. Fortunately Google and Mozilla are pretty aggressive about shutting down invalid certificate authorities, but it is a danger, and it's a possible attack vector out there. And it's happened before. So you think you're on facebook.com, and you're actually not on facebook.com.
[00:15:46] Even with the lock icon. So, nothing on the computer is 100% secure. Hopefully that explains a bit more about HTTPS.
>> Speaker 2: This question, do you keep backups of your SSH keys, like on a USB dongle or something?
>> Jem: Yes, I backup my, what do I back everything up to?
[00:16:07] It's one of the big cloud backup providers. Box? What's that?
>> Speaker 2: Dropbox.
>> Jem: No, not Dropbox, I do not use Dropbox to back up things. I forget the actual service, it's on my home computer. It just runs in the background. And yes, thank you. I use Backblaze to automatically image, not image, but it backs up all my folders.
[00:16:29] And I do keep a separate copy of my private keys and public keys on a USB dongle, disconnect it from my computer entirely. Because, again, if you lose your user private key, you are locked out completely. But, great question.
>> Speaker 2: Can gzip and HTTPS coexist on nginx.
>> Jem: Yes, I believe you can do both.
[00:16:50] Now, the question is HP2 and gzip, that's a good question. I believe you can still do both. But yeah, you can definitely do HTTPS and gzip on nginx. For those who don't know gzip is just a compression format for sending files on the internet. It's very, very well supported and by default I think gzip is on in nginx, so you really don't turn it on.
[00:17:17] Let me make sure. We can take a look actually
>> Jem: Maybe gzip is allowed by default.
>> Jem: Might not be on by default. But the turn on gzip in nginx, it's pretty easy. And I'm gonna Google how to do it cuz I don't remember off the top of my head.
[00:17:59] But this is how I solve most of my life's problems, by Googling it. Gzip, nginx.
>> Jem: And close this.
>> Jem: And DigitalOcean. I should've done another shoutout, DigitalOcean docs are phenomenal, their tutorials. They really go step by step they're much friendlier than most of the other tutorials. And honestly that's the one I use if I'm confused about a topic.
[00:18:32] So for this one gzip. No, no, this is way more complicated than I need. No, no. There we go. Start gzip on, I knew it was something easy. So I was gonna run this.
>> Jem: And let's pick a random spot. This is good enough. So, gzip, I believe it's just on, or whatever.
>> Jem: And we'll restart nginx
>> Jem: And that's it. Let's turn on gzip and nginx. I'm surprised it's not on by default. I thought it was. Yeah, and now we can shave off a few bytes off all of our requests.
>> Speaker 2: Another question. What he is saying is in that default config file there is a note that says, you should disable gzip for SSL traffic.
[00:19:48] So he is asking, should I turn it on or not.
>> Speaker 3: You should not compress encrypted traffic That and encrypt to compress traffic. Cuz it's like.
>> Jem: How would it know how to compress it? Yeah.
>> Speaker 2: No, it knows how to compress it, it just might make it twice as long.
>> Jem: Uncompressed as self traffic?
>> Speaker 2: Yeah, because it's. If you encrypt a certain way, then it expands the text. And if you compress that, it might increase the compression. Now, the flat file for example.
>> Jem: That's true. Yes, I guess that's why it's not all by default anymore.
>> Speaker 2: Yeah.
>> Jem: Because SSL is now the default for most browsers.
>> Speaker 2: Yeah.
>> Jem: So, since we're not serving over SSL, we're okay to throw on gzip, but again, we learn something every day. Again, I am no expert. I google just like the rest of you. I know a little something about a little something.
[00:20:42] But, great tips.
>> Jem: Any other questions?
>> Speaker 3: Just a quick thing. So it's basically saying that even if you, well one it's saying that they recommend you turn off the Droplet from the command line and not by the switch?
>> Jem: Really?
>> Speaker 3: Yeah, and they also said that even though you turn it off, you're still being billed for it.
[00:21:08] So then what's the point in turning it off?
>> Jem: That's true. I thought I read that they don't bill you anymore.
>> Speaker 3: I don't know. It's just the little pop-up that came up for me, cuz they said that you still are using up space. Cuz they're still charging
>> Speaker 2: For the droplets? I think they changed that now, even powered off you're getting charged.
>> Jem: Yeah, I thought they used to not charge you, but I think they're charging you for the storage, not so much for the usage anymore.
>> Speaker 3: Okay
>> Jem: The storage does cost a few dollars a month.
>> Speaker 2: It used to be you could spend a bunch, then turn them off and you got no charges, but I think they did change something, now there is a little charge still. You have to actually destroy them. Not to be not charged.
>> Jem: And I generally keep my server off if I don't need it just because there's a lot more encrypting a server.
[00:21:53] I use on my personal server I use a service, not a service, something called Fail2Ban which is pretty popular. Fail2Ban means all those people attacking my server, you have two tries to get a login right and if not I ban your IP address for an hour. Actually, I have it set for day, I'm pretty aggressive on it.
[00:22:10] And if you try it again within a certain timeframe, you're banned for a year. Which is pretty strict, but also means I can't mess with my logins. Cuz if I mess with my logins, I can get locked out of my own server. That's why I VPN in and then I would fix it.
[00:22:24] But, yeah, I didn't wanna get into Fail2Ban, cuz that's a little bit more advanced than the pretty basic class. But unless your server has Fail2Ban, people are free to just keep trying and trying and trying and trying and trying to break into your server. So it's something I recommend if you're gonna [CROSSTALK].
>> Speaker 3: The docs are pretty good. It's a pretty easy setup. But the docs are pretty good.
>> Jem: Yeah, and it's very commonly used. The docs are kind of old school. Let's see if I can, Fail2Ban.
>> Jem: Yeah, it's.
>> Speaker 2: That's just Wikimedia?
>> Jem: Yeah.
>> Speaker 3: Does DigitalOcean have a writeup on that?
>> Jem: That's a good question.
>> Jem: Nice, DigitalOcean again, we really should get sponsored by DigitalOcean, or I should get sponsored. All right, yeah. DigitalOcean has a tutorial on how to setup Fail2Ban on Ubuntu 14.04. Which likely will work on Ubuntu 16, but 14 is the, I believe it's the LTS version, which means it's gonna be around for a while.
[00:23:41] Which is probably why most.
>> Speaker 2: Actually- 16.04 is LTS as well.
>> Jem: Is it LTS?
>> Speaker 2: Yeah, yeah.
>> Jem: Okay.
>> Speaker 2: The .04s are LTS.
>> Jem: I did not know that. You are just killing it today, thank you. [LAUGH] All right, LCS just means it's going to be well supported.
[00:23:58] So if you have a company that you're processing credit card information or you have a real company where you make real money. You want to use a stable version of Ubuntu so you always want to use the LDS. The same with Node, Netflix would use the LTS version of Node, as well.
[00:24:12] Which means we're not on the latest, greatest, cutting edge, but we're on the most stable build. But this is great.
>> Jem: Yes, if you have a non toy site I recommend installing Fail2Ban just to install Fail2Ban Configuration. I think the default configuration is actually okay.
>> Jem: But yes.
>> Jem: Any other questions?
>> Jem: Nobody? All right, I didn't lose too many people. So I'm gonna push up the updated code to the repo. The slides will up. I'll keep them perpetuity. And I'll update them, or maybe I'll throw in something about Fail2Ban and further learnings. Where to go for SSL.
[00:25:11] How to set that up. Just so Jem.party is secured. Maybe I'll put a gif up there next week when I get home.
>> Jem: And
>> Jem: Yeah, that's it. Thank you everyone. It's been an excellent class. The questions have been on point. And hopefully you kind of just dip your toes into the end of backend or the full stack land.
[00:25:43] And you now feel comfortable at your own job just stake in a server, telling a log file, you understand what nginx is how to configure it. And you understand how to make an app from literally from nothing to something. So thank you.