Dockerizing

Hi,

Just curious if anyone has experience with dockerizing CS-CART and any snags you may have it.

I am trying to solidify my development and deployment of our CS-CART install.

A few questions:

- How to handle upgrades

- Would it be possible to use a docker volume (maybe connect to s3) for folders like ./images folder?

- How could I deploy a staging build to a different server compared to a production build

I'd be interested to hear any of your experience dealing with Docker and CS-CARt...

Hi,

Just curious if anyone has experience with dockerizing CS-CART and any snags you may have it.

I am trying to solidify my development and deployment of our CS-CART install.

A few questions:

- How to handle upgrades

- Would it be possible to use a docker volume (maybe connect to s3) for folders like ./images folder?

- How could I deploy a staging build to a different server compared to a production build

I'd be interested to hear any of your experience dealing with Docker and CS-CARt...

Hello,

We handle upgrades by first doing a local one, committing all the changes, and then executing all the upgrade migrations that are provided with an upgrade. We have also used CS-Carts internal github repository but that does mean you have to ask permission first.

Yes, you could use a docker volume for files, but its not recommended to use S3 then. Instead, you should probably use something like EFS, as its was made to work that way. S3 is meant to be used through an API.

You could make a staging server by using something like Elastic Beanstalk.

Kind regards,

Hello,

We handle upgrades by first doing a local one, committing all the changes, and then executing all the upgrade migrations that are provided with an upgrade. We have also used CS-Carts internal github repository but that does mean you have to ask permission first.

Yes, you could use a docker volume for files, but its not recommended to use S3 then. Instead, you should probably use something like EFS, as its was made to work that way. S3 is meant to be used through an API.

You could make a staging server by using something like Elastic Beanstalk.

Kind regards,

Great, thanks.

That makes sense. So you run the command line migrations on production prior to pulling in code changes? I didn't realise you could run the database migrations separate to the code updates.

The reason I wanted to use S3 was that we have custom addons, one of which is for our product brochures. All brochures have 1 page, but in special circumstances, some products have a second page with more detailed product specs on them. If a file is found in a particular folder that matches the product SKU, then this second page is appended to the PDF. The reason I wanted to use volumes was so that management could FTP directly into the folder and drop the second page PDF files as they were generated... But I gather the same would work for EFS....

How about deployment, do you use ECS for your containers?

I am trying to think of the simplest deploy method to aws. Traffic to our site is about 20K users per month with session times of about 4 minutes which is pretty modest. I keep thinking of dockerizing and using ECS, but maybe that is overkill.

Currently i run mysql on the same instance as the website. Although I think it makes sense to possibly push the database to its own VPC..

I would be interested in your thoughts.... thanks again

There is a solution on github

Thanks... I'll check it out.

There is a solution on github

Well, if you do use that, make sure to at least change the PHP settings. 100M upload limits for production is just a big no.

Great, thanks.

That makes sense. So you run the command line migrations on production prior to pulling in code changes? I didn't realise you could run the database migrations separate to the code updates.

The reason I wanted to use S3 was that we have custom addons, one of which is for our product brochures. All brochures have 1 page, but in special circumstances, some products have a second page with more detailed product specs on them. If a file is found in a particular folder that matches the product SKU, then this second page is appended to the PDF. The reason I wanted to use volumes was so that management could FTP directly into the folder and drop the second page PDF files as they were generated... But I gather the same would work for EFS....

How about deployment, do you use ECS for your containers?

I am trying to think of the simplest deploy method to aws. Traffic to our site is about 20K users per month with session times of about 4 minutes which is pretty modest. I keep thinking of dockerizing and using ECS, but maybe that is overkill.

Currently i run mysql on the same instance as the website. Although I think it makes sense to possibly push the database to its own VPC..

I would be interested in your thoughts.... thanks again

For deployment we use EKS and ECS. It depends on the needs one customer might have. Kubernetes works amazing for websites that only need 3 or 4 application servers, whilst something like ecs is generally more robust and is used along with amazon rds & elasticache to build a store able to withstand the traffic of a few thousand sessions at once.

Besides that, kubernetes also works way better for cross-cloud. As you can easily take your business to azure / google cloud within a few hours. Which is something that a lot of customers also prefer.

Regarding the simplets method to deploy to aws. Just create an aurora database (serverless), with elasticache, and install cscart on a single server. If time comes for autoscaling, its not even that hard to set up at that point. As you will just need to create a docker container for your application and register it accordingly.

Ok, we are just running a single instance of CS-CART at the moment on an ec2 for our production server. Database and redis are installed on the server... Which is probably an expensive way to run it... Would running it on beanstalk be suitable? We have about 20,000 users per month, so not super high traffic.

**EDIT**

Sorry, it has been a while since I read these posts, but reading your previous post makes sense to me now...

I am now thinking that we run with the kubernetes solution as it will perform like for like with our current solution, but also future proof us in that we would be able to scale up in the future...

Considering you obviously have more experience, does that approach sound logical?

One thing I may not have mentioned is that I currently use an NGINX proxy in front of my webserver for caching... would it be worth replacing this with elasticache? I have added some functions to my cscart addon that will clear nginx cache when things like product updates happen, product category reassignment etc.... rather than wiping the whole cache... I would need to consider how I do this in elasticache...

Ok, we are just running a single instance of CS-CART at the moment on an ec2 for our production server. Database and redis are installed on the server... Which is probably an expensive way to run it... Would running it on beanstalk be suitable? We have about 20,000 users per month, so not super high traffic.

**EDIT**

Sorry, it has been a while since I read these posts, but reading your previous post makes sense to me now...

I am now thinking that we run with the kubernetes solution as it will perform like for like with our current solution, but also future proof us in that we would be able to scale up in the future...

Considering you obviously have more experience, does that approach sound logical?

One thing I may not have mentioned is that I currently use an NGINX proxy in front of my webserver for caching... would it be worth replacing this with elasticache? I have added some functions to my cscart addon that will clear nginx cache when things like product updates happen, product category reassignment etc.... rather than wiping the whole cache... I would need to consider how I do this in elasticache...

You can still use nginx as a proxy. ElastiCache is just managed, scalable redis basically. Elastic Beanstalk is an option for sure, although I rather stick with cloud formation due to the fact that Beanstalk is fairly slow at updating (no PHP 8 support yet).