Running backend modules in pure Docker

[christophd]

This is a...

[x] Feature request
[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Documentation issue or request

Description

This is kind of a research task to see if we can run Syndesis backend core modules (server, meta and db) in pure Docker.

This would enable us to have local test environment where we can test the Syndesis integration design time with ui and backend involved. The UI itself could run locally or as another Docker image.

The setup should be more lightweight and less resource consuming than having Minishift or CodeRead Containers running locally.

Also we should be able to run some automated tests with this setup in CI.

In scope is everything up to designing/creating integrations/connections. Deployment of integrations and integration runtime in general is not in scope for this.

[zregvart]

While docker might be a nice distribution mechanism I don't think it's that good for development. It adds an additional step when one wants to build and see the changes.

So perhaps the module one is developing would be running outside of the container so you can make changes and immediately see the difference and the other modules that are not of concern could be run as containers.

I'm not sure I'll be using this mode, I prefer running the UI and the Server locally as standard processes.

[squakez]

Ideally you can have a sort of docker-compose with all the images configured. The problem there is that you need to maintain a local docker registry where your build will end up pushing the local changes of your images: right now this is transparently handled by the OC PAAS.

Also, another limitation would reside in the auth mechanism. Right now we are completely linked to OC.

Last thing would be to understand how to deploy an integration: also here I think we rely the PAAS to publish an image to the registry and suddenly run it as a container.

[KurtStam]

I'm with Zoran om this one where it'd be better to join efforts on a standalone #6556. As far as deploying goes we should target the CamelK era I think, where simply can drop a CamelK route on a (remote) Kubernetes.

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!