Optimizations for running in a container based via compose/Dockerfile in repo roo #328
Conversation
…a Dockerfile change - todo assess if anything ignored is still needed, this is a docker init default dockerignore
…y time we change anything in our code
don't wait 5 minutes to try again
| # C /chipper/jdocs | ||
| # A /chipper/jdocs/botSdkInfo.json # stores vector IP, etc | ||
| # A /chipper/jdocs/jdocs.json | ||
| # A /vosk # vosk model extracted here.. would like to move this into image build too (very early on) |
There was a problem hiding this comment.
This looks much more finished then the current solution. Would like to discuss the downloading of vosk in the image though. If updating is implemented for docker, then surely it would be less efficient to download vosk in the image everytime rather then once when needed? I think my intent was to keep the image a little smaller so when downloading it for a second time it wouldn't take as long (i have terrible internet speeds). Tell me if I'm incorrect though, I'm not the best with docker as you can see lol
There was a problem hiding this comment.
Absolutely makes sense to cache it in a volume.
There was a problem hiding this comment.
Definitely not a priority... it might be nice to combine mDNS + DHCP domain suffix search (i.e. my DHCP server provides .lan suffix and so escapepod.lan would be nice to try too)... or some way to otherwise provide a custom base_url to vector... just curious, is vector given the escapepod.local URL to connect back to? I haven't yet looked into that.
There was a problem hiding this comment.
I think it is given escapepod.local sadly. Although there may be a way to change it. It might be quite hard though.
There was a problem hiding this comment.
escapepod.local is a hard coded URL in Vector's firmware and cannot be changed.
| services: | ||
| wire-pod: | ||
| hostname: escapepod | ||
| build: . | ||
| network_mode: host # b/c mDNS escapepod.local broadcast... why use mDNS? people hosting a custom vector "server" are clearly capable of setting up a DNS record... |
There was a problem hiding this comment.
I used mDNS because it was simple to set up and didn't require a DNS record (which I couldn't do with my network setup). Although, if this is more efficient, go for it :)
You could also add in a volume for vectors images, I did this in another branch but if this gets merged it will be better in here:
volumes: - wire-pod-data:/chipper/ - wire-pod-model:/vosk/ - wire-pod-images:/images/ volumes: wire-pod-data: driver: local wire-pod-model: driver: local wire-pod-images: driver: local
There was a problem hiding this comment.
I took out the wire-pod-data:/chipper/ volume because it was a mix of state (i.e. vector config) and code (for chipper), thus to update the code I had to get rid of the volume.
Since I was just doing some initial testing, I didn't mind recreating state but I would much prefer to get state split out (ideally into one volume) and then I can update chipper code/executables via the image and get best of both worlds... that was next on my todo list :)
If this sounds interesting to you, I will proceed with it to make an example that we can use to later talk about updating the actual Dockerfile, etc.
There was a problem hiding this comment.
Oh no, 100% agree with you with the chipper thing. When I put that in, i5 wasn't meant to last, I knew it wasnt proper when doing it, but I didn't have the time to figure out what needed to be saved or forgotten so I just included everything. I meant to add a volume for the images vector takes.
I wanted to build/run based on the
compose.yamlfile in the repo root, so I made changes to build just about everything into the image (apt installs, some of vosk, download go mods, etc) and that really helped with startup time (takes ~2 seconds now on my raspberry pi 4B). And restarts are nearly instant as well.I'm sharing the changes if anyone else wants to copy them. And if there is an interest in merging some/all of the changes, I could help do that too.
Some of my changes seem to conflict with how the current
compose.yaml/Dockerfileare being used, so a blanket merge doesn't likely make sense.And, there are additional changes that would be useful:
jsonstate files and getting the image to build with those in a dedicated directory that could be setup as a docker volume to be able to recreate a container based on an updated image and not lose the server state. Right now, IIUC, state and chipper code overlap and so thejsonfiles need to be moved elsewhere at least as far as the container env is concerned. It appears that we might be able to setPackagedtrue to get them to be stored in a~/.configor similar dir?golangimage as a base to avoid needing to install go insetup.sh