I'm building a small web application for a personal project. It will be an Angular web application which will talk to a Spring-Boot service layer which in turn will read/write stuff to MongoDb.
I hope to host all this on a single EC2 instance in AWS. My question is how to configure a web server (like Apache but doesn't have to be) to 'beautify' the URLs a bit. Example, without touching anything angular will run at something like host:4200 and the service layer at host:8080. I will then have to map a proper domain to host in AWS, but the hiding of ports etc is where it gets murky for me.
I want to be able to hit my web app at domain.com (no ports etc) and I also want my service layer to ideally have a similar setup e.g. domain.com/service (no ports etc).
How do I configure a webservice to do this for me? Examples or pointers to specific examples would be ideal, but even a pointer to the right documentation will be helpful.
This thread is kind of similar to what I want but not too helpful: How to deploy Spring framework backend and Angular 2 frontend application in any online server?
You can use a setup with AWS CloudFront as reverse proxy and CDN cache. You can map the Domain Name and SSL Certificates(You can use AWS issued free SSL Certificates through AWS Certificate Manager) to CloudFront while the EC2 instance is plugged as an origin behind CloudFront as shown in the following diagram.
In the diagram I have optionally added, which is a common practice in designing applications in AWS.
Hosting the Angular App in S3
Using Autoscaling & Loadbalancing for EC2 instances.
You need to use Apache or other web server as a reverse proxy. Start here -
https://devops.profitbricks.com/tutorials/configure-apache-as-a-reverse-proxy-using-mod_proxy-on-ubuntu/
You then will need to setup a custom domain name. The easiest option is to just use an ELB (now called Classic Load Balancer). More details are here -
http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/using-domain-names-with-elb.html
Related
I basically have an API that is going to be used with a web app and a mobile app. I don't want the API to publically available, where should I deploy it then? is there a way without using AWS? Thanks, Nav :)
There are multiple ways of doing this. This is a sensitive topic, as this is an opinion-based field.
However, I will try to answer below - and challange your way of approaching this.
It really depends on your 'operational' skills, funds, need for security, deadline(s) etc.
Basically you need to make an endpoint available on the www, without everybody being able to connect.
You could either:
Deploy a virtual machine or web app. in Azure/AWS/GCP/... and whitelist the IP's you need to connect from.
Rent a VPS from any provider, and deploy your application here - Again, whitelisting. (Edit: Not phones, since this IP changes constantly. A proxy can be implemented here (potential bottleneck), or any authentication mechanism like OAuth, JWT, Certificates etc. can be implemented either on the ingress controller (e.g. NGINX) or the application itself.)
Deploy the application on your Home-PC, order a static IP to your home and make a forwarded port and set up security on your premise (not recommended, and raises and bunch of other headaches)
Get in touch with a company that hosts web applications (Can be quite expensive)
Based on the limited information provided in your question, there is a ton of options, nice-2-haves and factors that comes in to play when choosing the setup that suits your needs.
You should also consider; VPN usage, Backup/disaster recovery, data leaks, redundancy, the need for future deploys, how you would access your environment in six months....
I hope this answered your question, but also raised a few for you to answer yourself.
Finally, I'd recommend you looking for inspiration here.
EDIT:
Question:
Whitelisting mobile IP's.
VPS selected.
Answer:
This becomes quite a task when mobile phones tend to change IP's frequently.
Since you are looking further into the VPS setup, you are more in control of the setup and can choose to look into OAuth and JWT.
Links:
OAuth - https://oauth.net/getting-started/ https://developer.okta.com/blog/2019/01/22/oauth-api-keys-arent-safe-in-mobile-apps
NGINX JWT - https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-jwt-authentication/
So - At the end of the day, you can make your app use a proxy (potential bottleneck) and whitelist this IP, or make the endpoint open (any -> 443) and implement an authentication mechanism like the ones mentioned above.
Consider implementing a DMZ zone for incoming traffic from the web.
https://en.wikipedia.org/wiki/DMZ_(computing)
and put your application behind this zone, making sure that the only the DMZ zone is facing the internet, and the server hosting your application is talking to the server in the DMZ.
Again, this is quite a big topic and is hard to simplify to a stackoverflow post.
If you are hosting the app on AWS you have a couple of options.
API Gateway now supports private endpoints. These endpoints can not be called via the public internet. That means if your app is hosted on AWS only the internal services of the app can call the end point. i.e. front end to database etc. I've used this method for internal micro services such as placing in house app data onto kinesis streams.
Alternatively, if you don't want to use API Gateway you have lots of options. Most of which would involve you creating rest APIs from where ever you plan on hosting your code. This could be on the server it's self or some sort of container.
API Gateway Private Endpoint Reference:
https://aws.amazon.com/blogs/compute/introducing-amazon-api-gateway-private-endpoints/
I have an application that uses spring boot for a backend and Vue.js as a front end. I have packaged the app into a jar file and deployed to PCF with ease. The problem is the application uses API Keys from https://developer.clashroyale.com/#/getting-started ...these keys require you to input the IP Address that will be used...
Obviously my key will not work unless I give the correct IP address, so how do I retrieve the IP Address for my PCF application so I can generate the proper API Key?
Also, the documentation says that the IP will change with every deployment of my application... Which prompts the question :
Is it impossible to use API Keys that require static IP Addresses with PCF applications?
I have deployed this same application to amazon AWS and it worked because I have a static IP Address that I can use to register a key. I prefer to use PCF, but am having trouble setting it up.
I don't think you will be able to use that API on the PCF platform. Every time you either cf restage or anything to cause the container to be rebuilt/redeployed, the IP will change.
So in short yes, it's impossible: https://docs.run.pivotal.io/marketplace/external-ips.html
Your app will be run on any number of Diego Cells, which all have different IP addresses. There are a couple ways that traffic can leave your app and the Cell.
In some cases, outbound traffic may go through a NAT, in which case the number of possible IPs may be small and the IPs may not change often (or at all). In other cases, traffic may leave directly from the Diego Cell on which your application is running. In this case, there's a lot more IPs & the IPs will change any time your app is restarted.
If you're talking about some general installation of Cloud Foundry, it will depend on how the operators for that environment have set up the traffic to flow so you'd need to confirm with your operator to be certain.
If you're talking about Pivotal Web Services, outbound traffic will originate from the IP of the Cell on which your app is running. See the link in Francisco's post.
Having said all that, there's a hack that you can use to work around the behavior above. Route your traffic through a proxy. Traffic coming out of the proxy can be made to have a fixed IP address.
On PWS, there is a service in the marketplace available to do exactly this. It's called QuotaGuard.
https://docs.run.pivotal.io/marketplace/services/quotaguard.html
You don't have to use that service though, you could use any other service provider or you could even set up your own proxy. I would recommend using a service unless you know exactly what you are doing though. Setting up & securing a proxy is not trivial and an improperly secured proxy is bad not just for you as the owner but the whole Internet.
We're planning to develop some microservices based on the play framework. They will provide rest apis and lots of them will be using akka cluster/cluster-sharding under the hood.
We would like to have an api gateway that exposes the apis of our internal services, but we're facing one big issue:
- Multiple instances of each service will be running under some ip and port.
- How will the api gateway know where the services instances are running?
- Is there maybe something load-balancer-like for play that keeps track of all running services?
Which solution(s) could possibly fill the spot for the "API Gateway"/"Load Balancer"?
The question you're asking is not really related to play framework. And there is no single answer that would solve what you need.
You could start by reading akka Service Discovery and then make your choice based what fits you more.
We're building services with akka-http and use akka-cluster but use unrelated technologies to expose and run the services.
Check out
Kong for API Gateway
Consul for DNS based service discovery
docker swarm for running containers with mesh network for load balancing
You are looking for following components,
Service Registry : The whole point of this component is to keep track of "what service are running on what addresses". This can be as simple as a simple database which keeps entries for all the running services and their instances. Generally the orchestration service is responsible to register new service instances with Service Registry. Other choice can be to have instances themselves notify the service registry about their existence.
Service Health Checker : This component is mostly responsible for doing periodic runtime checks on the registered service instances and tell service registry if any of them is not working. The service registry implementation can then either mark these instances as "inactive" till they are found to be working by Service Health Checker in future (if ever).
Service Resolution : This is the conceptual component responsible for enabling a client to somehow get to the running service instances.
The whole of above components is called Service Discovery.
In your case, you have load-balancers which can act as a form of ServiceDiscovery.
I don't think load-balancers are going to change much over time unless you require a very advanced architecture, so your API gateway can simply "know" the url's to load-balancers for all your services. So, you don't really need service registry layer.
Now, your load-balancers inherently provide a health-check and quarantine mechanism for instances. So, you don't need an extra health check layer.
So, the only piece missing is to register your instances with the load balancer. This part you will have to figure out based on what your load-balancers are and what ecosystem they live in.
If you live in AWS ecosystem and your load balancers are ELB, then you should have things sorted out in that respect.
Based on Ivan's and Sarvesh's answers we did some research and discovered the netflix OSS projects.
Eureka can be used as service locator that integrates well with the Zuul api gateway. Sadly there's not much documentation on the configuration, so we looked further...
We've now finally choosen Kubernetes as Orchestator.
Kubernetes knows about all running containers, so there's no need for an external service locator like Eureka.
Traefik is an api gateway that utilizes the kuberentes api to discover all running microservices instances and does load balancing
Akka management finds all nodes via the kubernetes api and does the bootstrapping of the cluster for us.
Wondering if we can share session data between two servers (running different code) behind an Nginx reverse proxy.
To be precise, we have a legacy app in PHP running on an apache server. We are updating some functionality and hosting only that functionality on a separate server (nginx). Both apps update the same DB.
nginX uses load balancing/ reverse proxy URL rewritting techniques to decide which server to send the client to based on the URL path they use.
So, a person can add items to his virtual basket (held in session) on
the new server application.
He then decides to edit his personal information which is on the other server (Legacy).
Nginx uses it's reverse proxy/load balancing magic to decide which server to send the person to based on where an app is available.
The question is, how can a session created on one app server be available to another app server aswell? is it possible to setup the reverse proxy to store all session data and how. Please point me to the right direction of you can help with google links aswell.
your question has several possible answers. It all depends on the way the application is designed.
A possible scenario would be to keep session information on a database shared among different web heads. In this way the client, once authenticated will retrieve its "session status" regardless which server he is accessing in the final servers cluster backend.
Again, this depends very much on the way the application is/has been designed.
I think there is very little magic you can do on an old legacy application just by configuring the reverse proxy engine.
In the end, sessions are handled by the application server and not the proxy frontend.
I am hosting my website on S3.
On my local host I am using backboneJS above a PHP Rest API that uses mySQL as a database.
So i opened an EC2 to host my Rest API but then realized this means cross domain AJAX.
How can i use EC2 as a Rest API if my index.html sits on S3?
What are my other DB options for S3?
many thanks,
Your JavaScript is being executed on web pages served from S3, and it has to access a REST API from a server you run on EC2. Unless the web pages and server are in the same domain (say, example.com), this will be a cross-origin request, prohibited by browsers by default.
Solution 1: have your S3 pages and your EC2 server in the same domain. S3 allows static website hosting that makes your S3 objects (web pages) available at the address of your choice. Put them and your EC2 server at addresses on the same domain, and it can work.
Solution 2: have your REST API server allow cross-origin requests. Since you control this EC2 server you can modify it to tell web browsers to allow pages from other domains to make such requests to your server. This involves setting several headers on your responses, and usually requires your server to respond to HTTP OPTIONS requests properly, too. See the CORS specification to get started on that.
You also ask about other DB options. If you keep your own EC2 server to provide the REST API it can use pretty much any kind of database you like, either running on the same or other EC2 instances, or database-as-a-service offerings like AWS RDB or AWS DynamoDB. But if you want to connect to the database directly from your web pages' JavaScript you would have to use a service that provides an HTTP API directly and that supports CORS. RDB does not provide an HTTP API at all, and DynamoDB does not seem to support CORS at this time, so neither of them would work.