Hoping some CS-Cart Multi Vendor gurus can help me out with this. I haven't made much progress with the CS Cart support team, so I figured I'd pose my questions here.
So, here it is. I'm using AWS and using an ELB for SSL termination. That ELB, ideally, would then point to two NGINX servers that are cached optimized which then load balance to multiple (right now two) NGINX servers that host the CS-Cart MV app. I've moved what I can tell are "shared directories" (like var/cache) on an EFS volume mounted on both CS-Cart app servers so both apps share those shared files. For a clean explanation of what I have is below:
1 AWS EC2 Elastic Load Balancer
(load balancing to)
2 EC2 servers running NGINX optimized for caching
(load balancing to)
2 EC2 servers running CS-Cart MV
Eventually we'd run as many CS-Cart MV instances as we'd need to scale horizontally and to offer high availability. Pretty straight forward for modern high availability environments. So on to the problem:
With this setup, I eventually get too many redirect issues in the browser. My guess is that's because CS-Cart MV itself is trying to do some smart redirecting in the app basically sending the request back to the top of the funnel again (i.e. the ELB). Before the redirects issue pops up its FAST which is what I want and what I would expect. But ultimately requests fail because of too many redirects - again because my hunch is the CS Cart MV code is redirecting back to our host domain. I've been able to verify that the redirect is in the CS CartMV app code because requesting one of those servers directly, i.e. aws:8080 redirects me back to our host domain.
So, I guess my question is, how is CS Cart supposed to be configured for highly available environments? Does something within the CS Cart code need modified to support this? I'm pretty sure that some config (file or DB) redirects the browser to the host domain than the actual app server its being hosted on. Does anyone else have any experience with CS-Cart MV that could guide me down the right path config wise for CS-Cart so I can get this to work?
I do have experience with making CS-Cart applications highly available (besides my numerous AWS certifications, I also have made the needed code changes before).
No offence but with 2 posts, can you post some examples of your work.
Depends, I could, but then I would have to chase all companies that just blatantly copy and paste code (if I were to open source it) without reading the license. Therefore, if you are interested in such things, shoot an email and I would be happy to help you out.
Regarding companies who use my solutions, I'd first have to check if they are okay with me making public that I manage their AWS cloud infrastructure.
@theanalyst We had issues with SSL and Varnish...and to be honest, nginx can cache just as well as Varnish from what I understand without the added complexity of having Varnish in the mix.
@harmsmitsdev I'm not exactly sure in the posts you linked to where a "solution" exists. My understanding is with SSL enabled, and how CS-Cart does redirects, it creates a mess with a cache enabled nginx servers in the middle of an Elastic LB and the 2 app servers running CS-Cart. Have you successfully used AWS elastic load balancer (SSL termination here), NGINX cache LBs, and NGINX app servers running CS-Cart before? I'd be interested in your setup if you have. Thanks!
@theanalyst We had issues with SSL and Varnish...and to be honest, nginx can cache just as well as Varnish from what I understand without the added complexity of having Varnish in the mix.
@harmsmitsdev I'm not exactly sure in the posts you linked to where a "solution" exists. My understanding is with SSL enabled, and how CS-Cart does redirects, it creates a mess with a cache enabled nginx servers in the middle of an Elastic LB and the 2 app servers running CS-Cart. Have you successfully used AWS elastic load balancer (SSL termination here), NGINX cache LBs, and NGINX app servers running CS-Cart before? I'd be interested in your setup if you have. Thanks!
My configuration is as follows by default (of course this changes per users' need):
- For DNS I use Route53, as we can hand out different IP's per region.
- Because we extended CS-Cart's abstracted file system, we can use CloudFront for all static files.
- An Elastic Load-Balancer which terminates SSL (however, we don't have any problem with cache enabled nginx servers as we do not use them.) and with sticky sessions enabled.
- An ECS cluster. We build the application in advance and consequently register it to ECS. During the application build stage all smarty templates are compiled in advance and it is made sure that all translations are preloaded.
- A SQS mail queue is used to reduce the mail overhead. This is then handled by e.g. a T3 nodes that will send all mails asynchronously to avoid stalling in our main application.
- DynamoDB for the session store (so that the sessions can persistent asynchronously across multiple availability zones).
- Amazon Aurora as the database (because of its scaling capabilities and amazing backup tools).
- Per availability zone, I usually also have an ElastiCache cluster to cache things like product reviews as these do not update a lot of the time (same for URL's, for which the TTL is usually about 2 to 5 minutes).
Ok, thanks for sharing - that's actually very helpful that I can likely get this to the state I want.
I do have a question about how you've set up CS-Cart with multiple EC2 instances running. What do you set $config['http_host'] and $config['https_host'] to on each of your app servers that are running CS-Cart?
I discovered that I run into this issue even when I replace nginx caching with Varnish, something happens as the request gets passed from the ELB through the "cache layer" (varnish or nginx) to the actual app servers running CS-Cart. I'm thinking I have this weird redirect issue regardless but the extra layer of servers exacerbates the issue. Right now I have them set to our domain, but perhaps that isn't the right solution?
What I think is happening is once the request gets to CS-Cart, its thinking it needs to redirect to the right host, so it does and causes this endless loop of redirects.
Thanks for helping me learn a bit more about how this stuff works!
A bit more digging into CS-Cart's fn_redirect function, where the weirdness is happening, it appears I'm getting into this block of code for every request:
if ($is_permanent) {
header(‘HTTP/1.0 301 Moved Permanently’);
}
header('Location: ’ . $location);
exit;
}
towards the end of the method. Turns out ob_get_contents() returns nothing, so my guess is there's nothing in the output buffer for the request so its trying to do a redirect? We see 301 redirects in the logs, so it also appears to think this is a permanent redirect.
My knowledge of PHP is pretty limited (I write mostly Ruby these days), so I could be completely off base here. Just thought I'd provide a little more info to hopefully help resolve our issue.
I will note that we have both security settings for SSL (storefront & admin) checked, which I believe is appropriate.
I dug even further, and found out that this block of code in fn.control.php kicks us into this loop:
// if we are not on https but controller is secure, redirect to https
if (!defined('HTTPS') && $controller_secure_status === 'active') {
fn_redirect(Registry::get('config.https_location') . '/' . Registry::get('config.current_url'), false, true);
}
so I think that tells me that CS-Cart doesn't think HTTPS is not defined, but the controller is supposed to be secure? When I commented it out it turned out I wasn't on a secure connection, even though SSL is terminated at my ELB and passing the request to 2 NGINX servers that then pass to NGINX servers running CS-Cart (confusing probably). So I'm starting to think there's an NGINX config I'm possibly missing along the way here to ensure CS-Cart knows that the connection is secure and not to redirect.
For anyone that stumbles up this in the future, the problem was SSL had to be enabled for NGINX on every server the request goes through before getting to CS-Cart. CS-Cart gets confused if you try to do plain text behind, say, SSL termination at an AWS Elastic Load Balancer. So, I installed my SSL certs on all NGINX servers and the crazy re-directing went away.
For anyone that stumbles up this in the future, the problem was SSL had to be enabled for NGINX on every server the request goes through before getting to CS-Cart. CS-Cart gets confused if you try to do plain text behind, say, SSL termination at an AWS Elastic Load Balancer. So, I installed my SSL certs on all NGINX servers and the crazy re-directing went away.
I went back through my git history and found that I changed the following in `app/Tygh/Bootstrap.php` at line 226. I changed
For anyone that stumbles up this in the future, the problem was SSL had to be enabled for NGINX on every server the request goes through before getting to CS-Cart. CS-Cart gets confused if you try to do plain text behind, say, SSL termination at an AWS Elastic Load Balancer. So, I installed my SSL certs on all NGINX servers and the crazy re-directing went away.
I do have a question about how you've set up CS-Cart with multiple EC2 instances running. What do you set $config['http_host'] and $config['https_host'] to on each of your app servers that are running CS-Cart?
CS-Cart is a monolithic software, and any methods of deploying it across multiple servers impose a number of limitations and lead to various challenges. We have focused on optimizing server hardware and fine-tuning the software to ensure that our solutions are as efficient as possible when deployed on a single server. Containerization allows for easy migration of the project to another infrastructure if needed. In any case, if a single server can handle peak loads, it is more economically feasible to use one server. Only when its capacity is exceeded does it make sense to transition to a distributed infrastructure. However, ensuring the operation of a decentralized database alone may introduce a number of issues that will require not only hardware upgrades but also code optimization.