New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How are we supposed to deploy changes to production with zero downtime #29819
Comments
Hi @Eddcapone. Thank you for your report.
Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:
For more details, please, review the Magento Contributor Assistant documentation. Please, add a comment to assign the issue:
🕙 You can find the schedule on the Magento Community Calendar page. 📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket. 🎥 You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel ✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel |
IMO this is more related with infastructure how to delivery code than related with magento problem |
"So basically you need to have pre-production system deploy on that and apply to real live production" Like described in my workflow example? |
Hi @Eddcapone, For example you can look at https://github.com/jalogut/magento2-deployer-plus that supports zero downtime deployments Are you using magento cloud, some magento compatible hosting or developing infra yourself? —- |
Hi @ihor-sviziev. Thank you for working on this issue.
|
@ihor-sviziev Thank you. We are hosted on Rackspeed. I have a few questions:
Where did you read about this, it is not described in the documentation entry which you have posted. How is it done? How do I know if the queue workers are even running atm?
I guess this is done by calling
Can you please explain what this means in this context? |
|
Hi @Eddcapone, |
Not yet. I have some questions left.
|
About killing the cron jobs and message queues - you can see how magento does it in their deployment tool named ece tools About dumping sensitive data - you could remove whole section “system”, it should work without it |
|
I think these config params should be marked as "system specific", if they're not - seems like it's a bug. https://devdocs.magento.com/guides/v2.4/config-guide/prod/config-reference-sens.html |
"we're doing the same way on Magento OS, I believe for EE it should be the same." |
We just using custom bash script that does the same commands as I listed
above
…On Fri, 4 Sep 2020 at 15:21 Eddcapone ***@***.***> wrote:
"we're doing the same way on Magento OS, I believe for EE it should be the
same."
I still don't understand how you are doing it. Do you call a command or a
script to stop queue workers? How is it done?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#29819 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAOJOUKEGVDDWYYKCICQAQLSEDLVLANCNFSM4QQVEWQA>
.
|
Oh... so there is not even something official from magento? |
I think it’s just not documented. |
One last question. In the diagram you posted, it says "Stop Queue Workers". But are we supposed to start them again at some point or does this happen automatically? And do you mind to share your bash script for stopping queue workers? |
@Eddcapone, there is a feature request pending to introduce an official way to stop queue consumers, but it's not implemented yet. See "Problem 2" (A solution to "Problem 1" will make its introduction in Magento 2.4.1 btw, but it's not 100% implemented like I wanted it too, but it should be sufficient for most people, I haven't found time yet to properly report what's wrong with it yet, I'll try to do this one day, but I'm really busy) For now, if you haven't changed the default configuration, after you killed the consumers using some script, they will spawn again by the cron system. See here for some script we've been using to kill them: davidalger/capistrano-magento2#133 (comment) |
@ihor-sviziev 1. In your "deploy" phase, you have enabled the maintenance mode then disable it at the end of the process so I understand that "maintenance" mode is equal as downtime |
@onlinebizsoft, basically setup upgrade (with keep generated flag) is running on the add/update configuration phase on production environment. |
@ihor-sviziev in my opinion, we can't call that as zero downtime which misleads to readers. I think we should have something like this installed in the system Then we don't need enable/disable maintenance during "setup:upgrade". |
@onlinebizsoft in case when we don't have any config changes as data/schema upgrades - we shouldn't enable/disable maintenance as well as running setup upgrade. That means that your visitors will immediately see a new version w/o any interruptions. This mechanism was introduced in order to prevent having not expected issues. I'm not recommend disabling it without really knowing what you're doing. |
Summary (*)
Lets say you have two environments. A dev and a production. Now on dev make a change in your theme or in a module, and push the theme/module into production and execute the commands:
Now reload the frontend a second after firing up the command and you will get:
There has been an error processing your request
How are you supposed to bring the change to your production environment, without any downtime?
Examples (*)
Proposed solution
Is my workflow below good or bad and how should it be done instead?
WORKFLOW
I setup my project like this:
On Dev I am developing. If I am done with my development, then I push it via git to the branch
master
.Then I switch to Staging where the branch
master
is also checked out, and executegit pull
.Now I execute my commands to deploy static files. I am executing
grunt refresh
but you can also use(de_DE for german shops...) if you don't use grunt.
Important: Make sure that your
production
branch is not ignoring the folderspub/static/
andgenerated/
.Now commit the generated files to the branch
production
and push the branch. Then switch to master branch again.production
is checked out, executegit pull
and then clear the cache withphp bin/magento c:c
.Your new changes should be live now.
EDIT: It won't work this way, since you also have to execute
php bin/magento setup:upgrade
in production, which will cause downtime.Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.
The text was updated successfully, but these errors were encountered: