The JetRails Team is happy to announce the launch of our biggest and most impactful AutoPilot release ever. Based on the input from end users and developers, this release focuses on both feature enhancements and stability improvements.
After months of building and extensive testing we are pleased to present you the new AutoPilot release!
Since this is a long list, and nobody has time for all that, here is a summary of what’s included in this release:
- New application: WordPress!
- Ability to access backups without filing a support ticket!
- New Monitoring section with graphs!
- Support for Magento v2.4.7
- Support for Shopware v6.6.x
- Auxiliary (extra) servers
- Dedicated host for high speed code deployment
- Upgraded user permissions structure for deployments
- Cost estimator enhancements
These new features and enhancements are only for new deployments, your currently deployed environment is optimized for long term operation and stability, that means NO CHANGES. However, when you are pushing the next code release, it’s a great opportunity to redeploy to a new server and enable all of the latest and greatest features of AutoPilot.
Headline Features (BIG CHANGES)
- New application: WordPress
- Practically every customer who operates Magento or Shopware also has a WordPress site. Although customers have always been able to modify their Nginx configuration to run WordPress, we now have a template just for this app! For now, WP is available as a All-In-One deployment style which can scale vertically. In the future, an Auto-Scaling Cluster configuration will be released that will be able to scale vertically and auto-scale horizontally!
- New Monitoring section with Graphs
- What good is having servers if you don’t know how they’re feeling?! Now you don’t have to ask. For all new deployments there is a Monitoring tab that displays CPU, RAM, Disk, Bandwidth, number of Web Nodes, and many other relevant metrics. This is just the first release of Monitoring features, we have an entire roadmap of planned enhancements!
- Auxiliary (extra) servers
- The word “auxiliary” in this case refers to an extra server that performs a task that you don’t want to run on your main cluster. Sometimes you have to run a workflow that spikes the CPU or build an occasional report. Sometimes you have to recover a file from an archive. Or maybe you want to run a specific kind of monitoring on the rest of the cluster. There are endless uses for extra servers. Now you can spin up to three such servers and tear them down when the task is completed.
- Dedicated host for high-speed code deployment and cron jobs
- Previously when your team logged into bash shell/CLI they landed into a server whose primary job was to be a Web Node. Now, your login is directed into a jump host which is optimized for performing CPU and disk intensive tasks. In this configuration files upload faster, code compile and deployment is faster, and there is no concern for impacting web users when running cron jobs. You also benefit from smaller web nodes which has considerable cost savings
- New sizes added to recommended deployment
- There are now more options for resizing servers. Previously we provided “sane” defaults with what typical customers actually use. However, based on feedback, we uncorked the options and allow much smaller and much larger servers at every service tier.
- Ability to access backups without filing a support ticket!
- We have always had backups, that’s table stakes. Now, you can access those backups without filing a support ticket! Simply navigate to the Actions tab in your deployment and mount the backup to the Jump Host. Web files and Database backups are stored on different snapshots and can be recovered separately. And you can even mount backups from other deployments in your organization. This means that setting up a Dev or Staging server is just as easy as copying from a recent snapshot! Don’t forget to unmount it when you are done.
- Upgraded user permissions structure for deployments
- Since your login user has access to sudo (root access) it’s best not to publish code as this user. Now, the www-data user has ability to store .ssh keys so that your deployment pipeline can push code into the right place with correct permissions. This is a bit of a game-changer if we say so ourselves. And in case you are comfortable with your existing workflow, you can simply run the newly updated /var/www/<sitename>/scripts/post-deployment script to get all the permissions just right.
- Cost estimator enhancements
- The cost modeling engine has been fine tuned for more accurate estimates. Fine tuned here and there to reflect a more realistic estimate for Load Balancer and Backup costs.
Less Loud (but still important) Features
- New application versions:
- Support for Magento v2.4.7
- Support for Shopware v6.6.x
- New WordPress template for All-In-One
- DNS Resolver errors resolved!
- Sometimes you just have to use the same word in different ways. This is such a case. We received reports that customers saw DNS errors sporadically. These resolution errors have been resolved!
- Default NGINX blocks for files that shouldn’t be seen
- Sometimes we forget to remove files that shouldn’t be displayed such as .git or .svn or .htaccess. These and many more are blocked by default.
- Varnish service memory enhancement
- Caching with varnish is amazing when it works. New tunable options are available in /mnt/jrc-coms/vars-varnish to adjust settings that you should not touch unless you absolutely know what you’re doing!
- RabbitMQ misbehaving when waking up from hibernation
- Service had to be reinitialized after waking up from hibernation. This has been addressed.
- Yarn is globally installed for every version of Node
- Your developers will love this, even if the regular people don’t understand.