One of Control F1’s current projects is working alongside the RAC on their RAC Advance platform, a revolutionary new technology that uses the latest diagnostic software to deliver an enhanced breakdown service for customers.
As is so often the case when working with innovative new technologies, our team have uncovered a number of solutions and fixes that haven’t been documented in the past. And because we’re all about sharing, lead developer Phil Kendall explains here, (for the technically minded amongst you), some of the team’s learnings re: using MATLAB Compiler Runtime with AWS Elastic Beanstalk….
One of the components of the RAC Advance system (an ASP.NET web application) we’re working on makes use of MATLAB to perform some of the advanced calculations that make the platform a success.
In order to provide scalability and reliability, the component is deployed via AWS Elastic Beanstalk. When Control F1 began their work with the RAC, the component was hosted on a custom AMI which had to have the MATLAB Compiler Runtime manually installed, and then the AMI had to be maintained over time. One of the improvements we were hoping to make to the system was to reduce the number of manually maintained components in the system, so we began looking at whether it was possible to install the MATLAB Compiler Runtime automatically via Elastic Beanstalk’s configuration mechanism (.ebextensions).
To my slight surprise, this didn’t seem to be anything anyone had ever done before (or at least, had ever publicly documented how to do). Fortunately, the solution turned out to be not too complicated, although there are a couple of rough edges I’d like to smooth off:
- Download the appropriate version of the MATLAB Compiler Runtime from Mathworks’ website, and put this into an S3 bucket you control. You’ll need to make the file publicly readable.
- Create the following file and save it as “matlab.config” in a “.ebextensions” folder of your web application (note that the spacing is crucial here, and that’s it’s all spaces, not tabs):
command: setup.exe -agreeToLicense yes -mode silent
command: setx PATH "%PATH%;C:\Program Files\MATLAB\MATLAB Compiler Runtime\v82\runtime\win64"
(Note that the config files within the .ebextensions folder are run in alphabetical order so if you’ve already got other extensions in there, you may want to rename the file so that it’s run in the correct order).
To some extent, that’s all there is to it, but it’s probably worth an explanation as to how that’s working. Essentially, there are two main steps: the first, indicated by the “sources” stanza, downloads a ZIP file from the specified location (our S3 bucket) and expands it into the specified folder. While the MATLAB Compiler Runtime installer has an “.exe” extension, it’s actually a self-extracting ZIP file, and the Elastic Beanstalk functionality is perfectly happy to deal with this.
The second step is to actually run the installer – this is what is accomplished by the “01_install_matlab” stanza, which uses the silent install functionality of the installer. (If you’re using the 32-bit runtime, you’ll need to modify the path specified in the “cwd” line). Finally, we kick IIS to pick up a modified PATH which includes the native MATLAB DLLS (“03_reset_iis”).
While this solution works, as noted above there’s a couple of things I’d like to improve:
- Ideally, you wouldn’t have to make the file in the S3 bucket publicly readable. However, the “sources” functionality supports only publicly readable files at the moment, so there’s no easy way round this. It would be possible to install other components onto the box which would let you authenticate and download a protected file, but that seems like overkill. Hopefully Amazon will add authentication support for “sources” at some point.
- The observant will note I skipped over the “02_modify_path” stanza – what’s that for? As noted, when the MATLAB installer finishes, it modifies PATH to include the location of the native MATLAB DLLs. However, the installer runs as a background task, so the actual command returns instantly, and crucially before it has modified PATH. As far as I know, there’s no way of knowing when the installer has actually completed, so we bodge around this by manually adding what we know is going to be added to PATH, which means that IIS will be able to find the DLLs once they’ve been installed. This is obviously not the nicest solution in the world, but it works.
Hopefully this little guide helps anyone else who’s looking to do this sort of thing – please leave a comment if there’s anything you’d like to ask, or if you can help with those improvements!