Last week Nextcloud, Western Digital and Canonical launched the Nextcloud box, a simple box powered by a Raspberry Pi to easily build a private cloud storage service at home . With the Nextcloud box, you are already securely sharing files with your colleagues, friends, and/or family.
The team at Rocket.chat has been asking “Why not add a group chat so you can chat in real-time or leave messages for one another?”
We got in touch with the team to hear about their story!
Here’s Sing Li from Rocket.chat telling us about their journey to Ubuntu Core!
Rocket.chat is a slack-like server that you can run on your own servers or at home… and installing it with Ubuntu core couldn’t be easier. Your private chat server will be up and running in 2 minutes.
If you’ve not heard of them, Rocket.Chat is one of the largest MIT licenced open source group chat project on GitHub with over 200 global contributors, 9,000 stars, and 40,000 community servers deployed world-wide.
Rocket.chat is an optimized nodejs application, bundled in compressed tar zip. To install it a system admin would need to untar the optimized app, and install its dependency on the server . He/She would then need to configure the server via environment variables and be configured to survive restart using a service manager.. Combined with the typical routine of setting up and configuring a reverse proxy and getting DNS plus SSL set up correctly. This meant that system administrators had to spend on average 3 hours deploying the rocket.chat server before they can even start to see the first login page.
Being a mature production server, the configuration surface of Rocket.Chat is also very large. Currently we have over a hundred configurable settings for all sort of different use-cases. Getting configuration just right for a use-case adds to the already long time required to deploy the server.
Making installation a breeze
We started to look for alternatives that can ubiquitously delivery our server product to the largest possible body of end users (deployer of chat servers) and provide a non-complex, pleasant initial out-of-box experience. If it can help with updating of software and expediting installation of new version – it would be a bonus. If it can further reduce our complex build pipeline complexity, then it is a sure winner.
When we first saw snaps, we knew it had everything were looking for. The ubiquity of Ubuntu 16.04 LTS, Ubuntu 14.04 LTS, plus Ubuntu Core for IoT – means we can deliver Rocket.Chat to an incredibly large audience of server deployers globally – all via one single package. But also cater for the increasing number of users asking us to run a Rocket.chat server on a Raspberry Pi.
With Snap, we only have one bundle for all the Linux platforms supported. It is right here in the snap store What’s real cool is that even the formerly manually built ARM based server, for Raspberry Pi and other IoT devices, can also be part of the same snap. It enjoys the same simplicity of installation, and transactional update just like other Intel 64 bit Linux platforms.
Our next step will be to distribute our desktop client with snaps. We have a vision that once we tag a release, within seconds a build process is kicked off through the CI and published to the snap store.
The asymmetric nature of the snap delivery pipeline has definite benefits. By paying the cost of heavy processing work up front during the build phase, snap deployment is lightning fast. On most modern Intel servers or VPSes, `snap install rocketchat.server` takes only about 30 seconds. The server is ready to handle hundreds of users immediately, available at URL `http://<server address>:3000`.
Consistent with the snap design philosophy, we have done substantial engineering to come up with a default set of ready-to-go configuration settings that supports the most common use cases of a simple chat server.
What this enables us to do is to deliver a 30s “instantly gratifying” experience to system admistator who’d like to give Rocket.Chat server a try – with no obligation whatsover. Try it, if you like it, keep it and learn.
All of the complexity of configuring a full-fledged production server is folded away. The system administrator can learn more about configuration and customization at her/his own pace later.
Distributing updates in a flash
We work on new features on a develop branch (Github), and many of our community members test on this branch with us. Once the features are deemed stable, they are merged down to master (Github) where our official releases (Github) reside. Both branches are rigged to Continuous Integration via travis. Our travis script optimizes, compresses and bundle the distributions and then pushes them out to the various distribution channels that we support, many of them requires further special sub-builds and repackaging that can take substantial time.
Some distributions even calls for manual build every release. For example, we build manually for ARM architecture (Github), to support a growing community of Raspberry Pi makers, hobbyists, and IoT enthusiasts at Github
In addition to the server builds, we also have our desktop client(Github). Every new release requires a manual build on Windows, OSX, and Ubuntu. This build process requires a member of our team to physically login to a Windows(x86 and x86_64) OSX and Ubuntu(x86 and x86_64) machine to create our releases. Once this release was built, our users then had to goto our release page to manually download the Ubuntu release and install it.
That’s where snap also bring a greatt a much simpler distribution mechanism and a better user experience. When we add features and push new, every one of our users will be enjoying it within a few hours- automatically. The version update is transactional, so if they can always roll back to the previous version if they’d like.
In fact, we make use of the stable and edge channels corresponding to our master and develop branches. Community members helping us to test the latest software is on the edge channel , and often gets multiple updates throughout the day as we fix bugs and add new features.
We look forward to the point where our desktop client is also available as a snap and when our users no longer have to wrestle with updating their Desktop Clients. Like the server we are able to deliver their updates quickly and seamlessly.