You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Appliances would run within docker containers on a 1:1 basis.
Appliances would have a dockerfile.
The countertop would coordinate with the docker engine to set up and connect various appliances.
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.
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
The text was updated successfully, but these errors were encountered: