Some dos and don'ts for administering Rocket.Chat servers.
This follows comments here:
Rocket.Chat is open source. That does not mean that it is necessarily 'Free'.
It has some areas/features that require a licence to use but the code is still visible to all.
The company has to make some money somehow to pay developers and other employees.
It cannot sit and churn out 'free' code for you every month with nothing in return or it will go bankrupt and then no more code at all.
If you do not pay for support you have zero comeback with Rocket.Chat
They will help on a best effort basis, but with no guarantees.
If you use the Community Edition and don't pay then at least help others with your knowledge and experience.
Write some documentation. Help triage in the forums or bug tracker.
Do what I am doing right now!
Rocket.Chat follows an Agile release schedule.
The Sales, Product, and Development teams meet to agree forthcoming features and bugs fixes.
Development for the next release starts arounds the 1st of the month.
Around the 20th of the month developemt is frozen a RC - Release Canditate - is built for testing, followed by any number of updated RCs as they resoolve any bugs with it.
Full release occurs around the 30th/31st of each month.
A release does NOT consitute a guarantee of stabiilty for you.
It is a development cut that the team want to deliver and feel confident enough that it should work most of the time for most people without issues.
A large driver of this is paying Enterprise customers.
Rocket.Chat has a large system behind the scenes that you cannot see.
Bugs from github are pulled into their own backed systems.
Their code is then pushed to github.
So what you see in github is only a very small part of the story. There is far more that goes on than you realise.
Hence it appears that github is often quiet.
The team are making an effort to keep github more up to date and deal with issues that arise. But it is not the centre of their world!
It would be nice if more members of the COmmunity got involved in this.
You get to know the team more, find out more about current development plans, get involved in directing Rocket.Chat, and they are more likely to help you. Win win :-)
Do NOT use the 'latest' image, ever, unles you are either developing OR like to live very dangerously and enjoy nasty surpises like it's 7am on Monday morning and your server has backflipped into the lava and you are now faced with the wrath of many angry users.
https://docs.rocket.chat/deploy/deploy-rocket.chat/deploy-with-docker-and-docker-compose
Set the RELEASE variable in the .env to your desired Rocket.Chat version.
See our releases page and available docker images. Keeping the default release aslatest is not recommended.
Your server may get upgraded without warning. Do not do this.
You are at the mercy of whatever the developers choose to point to with 'latest' and there have been any number of issues and accidental mistakes with it over the years.
Search the interwebs for why not eg
https://medium.com/@mccode/the-misunderstood-docker-tag-latest-af3babfd6375
If you are shipping Docker images to a production environment, you should just ignore the latest tag. Don’t use it. Don’t be tempted by it. It’s easy to look at it and think that your deployment script should just pull “latest” and your build process will ensure that’s valid. It takes a lot of discipline to make that work. Just version your tags. Every time.
Read the changelog carefully.
Plan your upgrade strategy. Give yourself time to deal with issues. Notify users first.
If you can then run a test machine to see what may happen with your data.
Always run a backup BEFORE you upgrade. Preferably with Rocket stopped or offline so you lose nothing.
The Mongo DB schema may get upgraded and it may then prevent downgrade. This is not a Rocket.Chat issue. It is the way that Mongo works, and Rocket.Chat uses it.
Backup again somewhere else.
Always set the release version to a tag that you are happy with
Upgrade and watch the Mongo/Rocket logs for issues before letting users leap in.
Personally I always track a release behind eg
Current release is 6.9.1
I am using 6.8.x
When 6.10 drops I will then start the upgrade to 6.9.x unless I see other issues. You will still get around 5 months of support.
Don't.
Simple as that.
Updates can make structural changes to the Mongo DB (it's a reason wjy Mongo is used). Unless you absolutely know what you are doing, have several backups, and have tested thoroughly, do not try a downgrade.
It may work, and it may fail spectacularly. YMMV. Only the chnagelogs will really tell you. If oyu don;t understand, don't do it.
It is another reason to NOT use the 'latest' tag as above. Upgrade when you are prepared so you do not have to risk a downgrade.
Note that upgading to Mongo 5 which will become the minimum verison with Rocket.Chat 7 may cause issue on older machinery.
Mongo 5 requires the AVX CPU extensions to run. Check this before you start.
On Proxmox, if your underlying server supports AVX, you can put your VM in Host mode so the host will be able to access the servers extensions.
Release for snaps is around 15 days AFTER the main release. A large number of installs are snaps and they do some extra testing on a snap before release.
Snaps are quite well covered in the docs here:
https://docs.rocket.chat/deploy/deploy-rocket.chat/deploy-with-snaps
https://docs.rocket.chat/resources/frequently-asked-questions/deployment-faq/snaps-faq
Revison 0.3 Date 18th June 2024