My Docker engineer is sitting opposite me expressing vocally how much he hates Meteor.
Which makes me sad since it has been a very effective tool for our project.
We can’t use Galaxy since our application is latency sensitive and we are 200msec from the closest AWS region.
We have Docker, Kubernetes.
He is trying to “meteor build” and install on top of our usual Node base. We are experiencing a kind of dependency / version hell and the whole process is very black box and hard to understand and debug.
Is there a better way - are we taking the wrong approach?
I think its wrong by default for a Docker Engineer to hate an application or framework. Its not their responsibility. Actually the whole concept of ‘Docker Engineer’ doesn’t make sense to me. Its either a DevOps person or application developer… Its the application developer’s task to build a docker container. Application developers get to decide the best environment for their application, because they know where it runs best (makes sense right?). It’s the whole point of containerization!!
Aside from this. Building Meteor should be quite a trivial task and does not have to happen in a Docker container. I found it much easier to use Jenkins or AWS CodeStar to spin up a build slave. This slave is responsible for running tests, creating the built version of Meteor and optionally shoves it into a Docker container.
Its literally (assuming the application is located in a source folder):
cd src && meteor build --directory ../
cd ../bundle/programs/server && npm install --production
cd ../../../
node main.js