Open slifty opened 3 years ago
@chriszs does this capture the situation as you see it?
I think so. Would we want one Docker file/docker compose per recipe?
Yeah, I think that's the way to do it (since one recipe might require completely different things than another).
Of course if you get in there and find that direction feels problematic, that's fine to flag too!
Did some work on this. There are some unofficial and semi-official scripts for getting ccextractor to compile in Docker, but they've taken some sorting through.
Discussion
What do you want to talk about?
We have talked about Docker a few times, and in a few different contexts. Now that the architecture has taken more shape I'd like us to revisit the conversation in order to create some more compelling developer stories.
Here are some places Docker could make sense:
Recipes Our cookbook has some example TV Kitchen implementations. At the very least it would make sense to have Docker be the standard mechanism for running a given recipe.
This would mean that
yarn start extracting-captions
would leverage docker compose instead of node directly. The recipe would run in docker, (and... maybe log output to stdout? I don't know for sure...). This would mean that developers would no longer have to install things like ffmpeg or ccextractor in order to invoke a recipe.This would also mean that each recipe would provide a dockerfile which sets up any file requirement.
Appliances In the mid term, however, I think it would be really cool for individual appliances to run inside of individual containers that are fully set up with any dependencies. This would mean that even outside of recipes, we could just say something like "if you have docker installed, you're set to use any TVK appliance".
Of course, we could make this an optional flag when setting up a countertop (so people who want to just run appliances without containers, could do so).
In this model:
This won't make sense to do without first addressing #17. Once appliances function as pipes, I believe Docker makes it straightforward to expose pipes to / from a given container.
This approach would probably involve creating a
docker-appliance
repository which would be set up to connect a given IAppliance with the docker's stdin / stdout.Relevant Resources / Research