gchq / gaffer-docker

Gaffer Docker images and associated Helm charts for deploying on Kubernetes
https://gchq.github.io/gaffer-docker
Apache License 2.0
30 stars 36 forks source link

Gh-334: Smoother gaffer gremlin deployment #337

Closed tb06904 closed 7 months ago

tb06904 commented 9 months ago

Adds a new gaffer-gremlin container image that comes pre-configured to run a gremlin server with the gafferpop library using a proxy store to point at an existing Gaffer instance. Now the gaffer docs have been updated too there is a guide for users on configuring this container.

Also integrated the image build into the CI and tidied a few bits up.

Related issue

tb06904 commented 9 months ago

For consistency I don't think we should be adding a new Dockerfile with a different approach to building compared to what has been done before, especially as the existing Dockerfile can simply be reused.

I would suggest keeping the existing structure and not adding the new gremlin-gaffer-demo directory, but instead create a directory under gaffer-gremlin for the demo. These can then use docker-compose for build/deployment, as done with all other images.

I'd suggest this layout

gaffer-gremlin
├── demo
│   ├── docker-compose.yaml to run the demo
│   └── other files for demo use (inc README)
├── proxy
│   ├── docker-compose.yaml to run the proxy
│   └── other files for proxy use (inc README)
├── Dockerfile
└── High level README.md

Or the proxy config could sit in the root directory for simplicity as this would be the more common usage.

Missed this comment before committing but changes implemented pretty much are along these lines, moving into an example directory and having the proxy at the top level as its the default files in the built image (I'll add the compose file though). I'm still not sure I agree with not changing things for consistency though when there improvements that can be made, maven should really be used for dependency management of the Jars not hardcoded URLs.

rj77259 commented 8 months ago

For consistency I don't think we should be adding a new Dockerfile with a different approach to building compared to what has been done before, especially as the existing Dockerfile can simply be reused. I would suggest keeping the existing structure and not adding the new gremlin-gaffer-demo directory, but instead create a directory under gaffer-gremlin for the demo. These can then use docker-compose for build/deployment, as done with all other images. I'd suggest this layout

gaffer-gremlin
├── demo
│   ├── docker-compose.yaml to run the demo
│   └── other files for demo use (inc README)
├── proxy
│   ├── docker-compose.yaml to run the proxy
│   └── other files for proxy use (inc README)
├── Dockerfile
└── High level README.md

Or the proxy config could sit in the root directory for simplicity as this would be the more common usage.

Missed this comment before committing but changes implemented pretty much are along these lines, moving into an example directory and having the proxy at the top level as its the default files in the built image (I'll add the compose file though). I'm still not sure I agree with not changing things for consistency though when there improvements that can be made, maven should really be used for dependency management of the Jars not hardcoded URLs.

I agree with tb here that we shouldn't be hardcoding URLs. If we change anything in the future we would have to change all the files which isn't best practice. Maven should do the heavy lifting. After all it is a dependency manager for a reason.