Hello,
We have an application which is written in ruby, but for which the documentation requires a processing tool written in nodejs. I can think of two simple solutions to do this:
1) Manually add nodejs in requirements.apt and then add suitable entries in tsuru.yml; e.g. something like:
hooks:
build:
- sudo ln -s /usr/bin/nodejs /usr/bin/node
- mkdir documentation
- npm install && npm run build
This is fine for a one-off app but it's likely we'll have other apps with this requirement, meaning we'd need to make similar changes to those too.
2) Create a locally managed platform which has a hybrid of the existing tsuru-official platforms for nodejs and ruby.
This solution would be relatively tidy, but it doesn't scale: what if we want to do the same for python, or go, or both… A second drawback is that when changes are made to the tsuru-offical platforms, we'd need to back port these changes. A third drawback is what happens if the need for nodejs (or whatever) in addition to the primary language is only discovered after the application has existed for a while… you could delete the app and then recreate it under the new platform but this would lose the app's history and would require the permissions and any environment variables and services to be set up again.
Perhaps a solution to this third problem would be to add a new switch to the tsuru app-update command in order to allow changing of the app's platform. Is it just a matter of updating the one attribute framework in the apps collection of the tsuru database? I'm happy to have a go at writing a patch if this is the case, but not knowing the underlying mongo data format well I couldn't say if this would cause problems when doing a rollback or other operation which touches historical deploy versions.
A more complex solution has come to mind:
3) Change platform to be a list instead of a single value attribute which during a deploy would then go through each of the appropriate runtime system setup. This would probably be a complete overhaul of the platform system within tsuru. Though a lot of work, it would mean that you wouldn't have the huge numbers of platforms for every required combination of language runtime and would also benefit from the consistency of the tsuru-official platform definitions. In light of the complexity of this third option it's likely that the benefit does not outweigh the amount of work necessary, but I wanted to at least offer the suggestion.
Is anyone else using hybrid language apps, and if so what solution are you using?
Matt Peperell