Closed kennethklee closed 4 years ago
Ah sweet,
So I am in two minds about this due to the fact that Docker is all about microservices, but then again I get the appeal of being able to spin one docker image (especially for people who will never interact with the API direct or people who land directly on Snake and don't care about core/skin/pit).
I don't know what your thoughts are on this but I am thinking that we should provide the above image for your use case above, while maintaining the individual Dockerfiles in their respective repos. We can then provide one of the following:
Do you have any strong thoughts on this?
two docker compose files might get confusing to users.
I like the sound of keeping the current docker-compose since the image would become self contained.
let me know what you'd like to do and I'll make the appropriate changes.
On second thoughts lets go with what you have, this then lets us have snake
, snake-core
and snake-skin
. Most users will use snake
and power users can then use the individual images if needed. This also makes adding snake scales easier as core and pit are one image as you have already said above.
Thought snake-skin and snake-core are closely tied together so would be helpful to combine them in a single docker image. As a benefit, makes it a lot easier to run snake without a docker-compose.
This PR combines snake-skin, snake-core, and snake-pit into one docker image to make it easier to launch. Left a way to run snake-core and snake-pit separately as well via the entrypoint.sh with
snake-core
andsnake-pit
commands.Changes:
snake-core
orsnake-pit
or bothSNAKE_PIT_CONCURRENCY
env variable for fine-tuning