I have both an Ionic and a Rails application. I'm currently wanting to push both apps onto the same EC2 instance. Ionic will act as a login section and several other pages. The rails application is intended to be a shopping cart and is only accessible when a user is logged in. I'm confused on a couple of points.
Am I right to believe both apps should be under different subdomains? Can I instead push both apps to two separate servers while still maintaining two separate subdomains? If two separate servers are used, can I expect sessions and localStorage to work across both applications? Thanks!
I assume that you are mixing up many things.
Domains & Subdomains
Let me explain that point with an example :
sub.example.com : first subdomain
other.example.com : second subdomain
Domains and subdomain are pointer to a server ip. Therefore, both example can point to the same EC2 instance.
The domain and subdomain shall therefore not enter into consideration into your analysis.
Webserver & Session Management
I'm not an expert and that point at all, but the magic is performed generaly here to share information & Sessions.
Common Webservers are Apache / Tomcat or even Jetty.
Some person use for session management REDIS too
LocalStorage
Correct me if I'm wrong, but localStorage can't be shared from one site to another.
Your problem resides more into this question :
What webserver am I using ?
Or : How Tomcat7 manage sessions ?
Or : Can I share session from different Webservers ?
Related
This is my first VPS, so I am pretty new to administrating my own box. I already have experience with a managed web server, registrars, DNS settings, etc. The basics. Now I'd like to take it a step further and manage my own VPS to run multiple services for different business and private projects.
So far I got an VPS from Contabo, updated the system, set up a new user with sudo rights, secured the root user, configured Ufw, installed Nginx with server blocks for two domains and created SSL certificates for one domain using Certbot.
Before I go on with setting up my VPS, I'd like to verify my approach for hosting multiple services for multiple domains makes sense and is a good way to go.
My goal is to host the following services on my VPS. Some of them will be used by all projects some only by a single one:
static website hosting
dynamic website hosting with a lightweight CMS
send and receive emails
Nextcloud/Owncloud
Ghost blog
My current approach is to run all services except for Nginx and the mail server with Docker. Using Nginx as proxy to the services encapsulated in Docker.
Is this an overkill or a valid way to go forward in order to keep the system nice and clean? Since I am new to all of this, I am unsure if I also could run all of the services without using Docker but still be able to serve the different projects on different domains without messing up the system.
Furthermore, I'd like to make sure, that access to the services and the stored data is properly separated between the different tenants (projects). And of course ideally the admin of the services is kind of manageable.
I want to add a new project beside of my current rails app without starting a new server for that.
I think it is impossible to have two rails app on one port but my boss want it.
Is it possible at all?
Yes it's possible if you configure a web server (nginx, etc) as a reverse proxy to listen on the port you want, and have it forward traffic to the correct app based on subdomain.
Yes and no. You can't run two web servers, e.g. Puma, on the same port. That won't work. But you can run one web server to serve two Rails apps. Incoming requests are routed based on either their subdomain (app1.example.com) or their path (example.com/app1).
A common setup is to use Apache/nginx as the web server in combination with Passenger as the application server. This question ask a similar question and points to Passenger's documentation on how to serve apps from subdomains: How to deploy multiple rails app on a single IP (Apache + Passenger)?
The configuration depends heavily on your setup, so I can't give you a more detailed answer. But searching for "multiple apps" and the combination of your web and application server should yield enough results and tutorials for you to solve your problem.
With our company, we sell a service to our customers,
this is a website which let customers enter some parameters and informations, and then, they can query a web service to get
the previous informations computed. These web sites are hosted on our servers.
We would have on our servers one database per client (dbo.Client1, dbo.Client2...) with the same schema.
And we would like to provide a different url for each client :
expl :
www.client1.service.com www.client1.ws.com/compute
www.client2.service.com www.client2.ws.com/compute
But i'm wondering how to deploy easily the web services and the web site?
Do i have to deploy one web service and one website per client (with different web config)?
And maybe create multiple deployment scripts ?
Or is it possible to imagine one instance of each (web service and web site), listening on several addresses, and creating different
connection string according to the entry point of the request (is it even possible with MVC or WCF ?)
Any other idea ?
I don't know what is the best practice here.
Thank you.
if anybody read that question one day, i solve my problem using multi-tenant solution, which allow me to deploy only one instance of the site.
The site handle the webrequest, and according to the host, connect to different database.
I am running a Rails app on the AWS infrastructure using several EC2 instances, a RDS DB, a round robin session-sticky load balancer and Route 53.
The application is serving pages for several domain names (same app looks and functions different depending on domain name).
The Rails code is hosted on a NFS share on a staging instance where the web server is running in development mode, while the other boxes load the apache config and application code via NFS and run in production mode.
What I'd like to do is to SSL-enable the whole thing as we're starting to process payments and whatnot. Due to the nature of the application and the heavy apache/Passenger optimization in place, I can't set up a vhost for each domain, but rather use a wildcard for www.* to load pretty much the same code, and the app does the rest internally.
Haven't really been able to figure out an ideal way to resolve this. Would anyone have an idea?
Thanks!
After a bit of discussion in the comments we came to this conclusion:
The application is currently hosted in one single <vhost> on Apache where the Application does the differentiation between hostnames for the different layouts.
The problem here is to support SSL without having to setup each domain with it's own certificate and a different vhost as that would require running the Rails app multiple times where it's unnecessary.
By using a Multiple Domain Certificate (MDC) this problem can be solved with only one vhost and one certificate, but MDCs are more expensive than normal certificates. So depending on the number of domains you need to support it may be cheaper/easier to just do it manually with multiple certs, or opt to pay the more expensive MDC but save time and maintenance cost.
While at it I found this nice wikipedia comparison of Certificate Authorities and their trust level in different browsers:
http://en.wikipedia.org/wiki/Comparison_of_SSL_certificates_for_web_servers
There is an option for us to have 2 or more web roles in a single deployment. But each deployment can be either be staging or production i.e. by extension, we get only 1 URL to access that deployment.
Considering this case how to access the different webroles, what will be the URLs for those.Also what is the use for having multiple webroles in a single deployment.
Why multiple web roles in a single deployment? Consider an application with a public-facing (customer-oriented) website, as well as an administrative website (maybe on port 8000). There are two basic ways to handle this:
Place both sites in the same web role. This means they now share the VM instances, network cards, memory, etc. It also means that, should you need to scale to handle traffic, both sites are scaled together as a single unit.
Place each site in its own role. Now, they're in their own VM instances and may be scaled separately.
Option #1 is more cost-effective because you can get by with only two role instances (minimum two needed for SLA). Option #2 is better for independent scaling. for instance: If you get a huge spike in customer traffic, this could cause trouble for you when trying to access the administrative website, whereas if your admin website is in its own role, it won't be affected by customer traffic.
In both cases, you get one IP addres, one *.cloudapp.net name (and you can map a custom domain name to it with a CNAME).
Staging vs. Production: Your entire deployment may be published to either Staging or Production (or both, as two separate publishes). Staging is not meant for external users - it's really meant for a pre-live area, where you can verify that a new deployment works as expected. You can then perform a virtual IP swap with your currently-running system in Production, which effectively swaps your staging and production deployments. This results in a near-instant upgrade of your software with no customer downtime.
Keep in mind: Every role in a deployment must stay together - you can't deploy one role to one service and the other role to another service. If you want to do this: Separate your roles into separate deployments. Then you can publish them to different URLs.
In a production deployment your webrole can be accessed by the URL with a prefix you defined previously for example myapp.cloudapp.net; web roles in staging deployment on the other hand can be accessed by automatically generated URL for example 205521014d8c440a83852b62e0df9db5.cloudapp.net
I am afraid there is no way to access web role instance directly, bypassing AppFabric router. Why would you ever need to do it anyway?
If you need get access from one web role instance to another, consider using a queue or distributed cache instead of direct communication.