|
|
|
|
|
|
Win a copy of Rust Web Development this week in the Other Languages forum!
|
|
|
|
|
|
|
Ranch Hand Scavenger Hunt
Greenhorn Scavenger Hunt
Tim Holloway wrote:You are confusing the Amazon Control Panel server with your Amazon instance. They are two different servers with 2 different IP addresses.
The Control panel app belongs to Amazon and doesn't run on the same VM as your AWS instance does or even the same subnet. The firewall to their server is open, since otherwise you wouldn't be able to talk to the control panel app. But the Amazon firewall to your server is not open and you need to use the Amazon Control Panel app to change that.
Tim Holloway wrote:Yes, you absolutely must open up Amazon's firewall. As I said, your browser probably already was set up that way because outbound traffic is rarely firewalled. But traffic inbound to Amazon's public IP address does have to be enabled via the Amazon control panel app. The default is to forbid it.
Again, I cannot see any ports on 34.218.234.4 and that includes the SSH port, so I have to question if your screenshot is current because I'm virtually certain that either the machine is down or you're not even able to connect to it via SSH, much less the web port.
Tim Holloway wrote:I'm afraid I don't have much use for videos myself. I prefer text that I can jump around in and hold onto.
But regardless, when you say you have opened the firewall on "your machine", do you mean your machine or the Amazon EC2 machine? Because your machine probably has the ability to make outbound requests by default, but unless you open up the Amazon firewall, that won't help.
Beyond that, a quick check of IP 34.218.234.4 indicates that no ports are open, including the SSH access, so that machine is evidently down at the moment.
Bear in mind that Amazon dynamically assigns IP addresses and routes through internal networking, and that you may no longer be talking to the proper host.
Tim Holloway wrote:OK. Bear with me. I tend to get S3 (object storage) and EC2 (Elastic Cloud Computing) confused. Acronyms can be more trouble than they're worth sometimes.
EC2 provides VM instances. Now actually, for this app, I'd look at Elastic Beanstalk rather than an entire personal VM, but it's a matter of preference.
To run a Spring Boot app in EC2, you need to do the following:
1. Create an EC2 instance and launch it.
2. Upload your Spring Boot Jar and launch it.
3. Ensure that the Amazon Firewall to that EC2 instance has the proper ports open. In other words, if you're blocking port 8080 (which Amazon will do by default), then external clients won't be able to talk to the app.
Here I'd like to note that 8080 is not the default port for HTTP. That's port 80, so you have to include an explicit override in your URLs. And since port 80 is a protected port, the only ways that you can make a Spring Boot app visible on port 80 are to A) override its default setting and run as a privileged user (NOT recommended) or B) proxy from a server that can service port 80 to the Spring Boot app using a proxy server such as Apache or Nginx. This is actually the better approach when hosting multiple Spring Boot apps on the same server instance.
Tim Holloway wrote:I haven't the faintest idea of what any of that is supposed to mean.
The first URL times out because it's addressing a specific AWS instance that you created which isn't running any more. The other URLs appear to simply access the JAR as an object stored in EC2, but I have no clue as to what that's supposed to be doing for you.
Tim Holloway wrote:Why are you storing an executable application in S3 storage? Aren't you deploying it to the Amazon cloud?
Number Threads Started (62/100)