Hybrid platforms

[ma...@automationlogic.com]

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

[Cezar Sá Espinola]

Hey Matt,

We do have some situations where an application needs two or more languages installed in the container. We usually solve it with the number 1 approach.

The solution 2 is very good alternative though, and I don't think keeping up-to-date with the base platform is too big of a problem. You can create a Docker image inheriting from the original platform (i.e. FROM tsuru/python) and simply add a few RUN commands doing something similar to what you would do on the build hook. If you setup an automated build on Docker Hub it will even rebuild your image automatically when the base platform is updated.

Allowing app-update to change an app platform is perfectly possible. As you said, besides updating the framework attribute we would also need to set the updateplatform flag to true. This would ensure that the new platform image is used on the next deploy.

Option 3 would be really tricky and I also wouldn't like to see this kind of complexity added to the build process. There are several pitfalls, like which artifacts would be carried from one build phase to the next and how to merge them.   

So, if this kind of situation is common for you, I would suggest going with option 2. We would gladly accept contributions to app-update. :)

Best,

--

Cezar Sá Espinola

--
You received this message because you are subscribed to the Google Groups "tsuru" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tsuru-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.