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 18.104.22.168 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 22.214.171.124 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?
Al Hobbs wrote:Where are you running that command exactly?
Tim Holloway wrote:Oracle's JDK is not "open", it's just that they have relaxed license terms. Even Sun's JDK was not open-source. Oracle contributed to the development of OpenJDK, but their binaries are built from their proprietary source code, not the OpenJDK source code.
OpenJDK, on the other hand, is 100% open-source. You can download the source code, compile it, even customize it - though redistributing the modifications may be licence-restricted.
Azul has taken OpenJDK, built their own binaries and sells them with paid support. Much like you can obtain paid support for the PostgreSQL database even though it is free with many Linux distros.
Speaking of Linux distros, most of them include OpenJDK and some even appear to install it as part of basic OS installation. The distro builders simply wrap their own distro build processes around the basic OpenJDK source to create an OpenJDK OS package. The difference between them and Azul is that they only provide support for the package, and little or no support for problems internal to OpenJDK.