-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimizations for running in a container based via compose/Dockerfile in repo roo #328
base: main
Are you sure you want to change the base?
Changes from all commits
e3838c5
c2051b0
41b1296
50db1ad
587c255
4beed32
f92430b
008ab51
5649ea3
59746df
e783a77
7e6408e
06aa697
7fbac38
7b93b98
cea58c9
1add7ff
4988913
93795df
aba6bcd
aaecfee
7e008db
dbf2f68
4fb4a25
6d70ece
df4cccd
bc7904b
14cf992
71260cf
8404189
6a4799b
bdd3bd8
9878bf9
86e1321
720cd21
ef47afe
2cfed93
ab5791a
4eb8a77
5bec26b
08012ed
1550447
d66ec45
0c3d609
3d6227d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,39 @@ | ||
# manual ignores: | ||
**/.github | ||
**/dockerfile* | ||
|
||
# Include any files or directories that you don't want to be copied to your | ||
# container here (e.g., local build artifacts, temporary files, etc.). | ||
# | ||
# For more help, visit the .dockerignore file reference guide at | ||
# https://docs.docker.com/go/build-context-dockerignore/ | ||
# | ||
|
||
**/.DS_Store | ||
**/__pycache__ | ||
**/.venv | ||
**/.classpath | ||
**/.dockerignore | ||
**/.env | ||
**/.git | ||
**/.gitignore | ||
**/.project | ||
**/.settings | ||
**/.toolstarget | ||
**/.vs | ||
**/.vscode | ||
**/*.*proj.user | ||
**/*.dbmdl | ||
**/*.jfm | ||
**/bin | ||
**/charts | ||
**/docker-compose* | ||
**/compose.y*ml | ||
**/Dockerfile* | ||
**/node_modules | ||
**/npm-debug.log | ||
**/obj | ||
**/secrets.dev.yaml | ||
**/values.dev.yaml | ||
LICENSE | ||
README.md |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,9 @@ | ||
version: '3.8' | ||
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... | ||
platform: linux/arm64 | ||
image: ghcr.io/kercre123/wire-pod:main | ||
restart: unless-stopped | ||
ports: | ||
|
@@ -10,10 +12,22 @@ services: | |
- 80:80 | ||
- 8084:8084 | ||
volumes: | ||
- wire-pod-data:/chipper/ | ||
# FYI after setup new server and join vector to it... diff shows only these changed files: | ||
# $ docker container diff wire-pod-wire-pod-run-b2a5f3d4bf75 | ||
# A /certs | ||
# A /certs/server_config.json | ||
# C /chipper | ||
# A /chipper/apiConfig.json # stores config for first Submit Settings page (i.e. openai api key, weather api key, etc.) | ||
# 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Absolutely makes sense to cache it in a volume. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
# TODO this is a problem to use a volume for /chipper in terms of updates, can we split out just the part that has the database we need to preserve and not cache the codebase? otherwise once created it will never update if image contents change... admittedly the compose file here does not appear designed for the use case of updating at all (neither via a volume nor via the image...?) ... appears that update.sh uses git to pull latest code?! from this repo... so my dockerignore on .git is not gonna be so helpful then :) | ||
# /root/.anki_vector/* ??? is this the path? if so make a volume for this | ||
# - wire-pod-data:/chipper/ | ||
- wire-pod-model:/vosk/ | ||
volumes: | ||
wire-pod-data: | ||
driver: local | ||
# wire-pod-data: | ||
# driver: local | ||
wire-pod-model: | ||
driver: local |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,12 +1,45 @@ | ||
FROM ubuntu | ||
|
||
|
||
COPY . . | ||
# *** PACKAGE INSTALLS *** | ||
# install packages before copying in source so we don't do this on every source change | ||
RUN apt-get update && \ | ||
apt-get install -y dos2unix avahi-daemon avahi-autoipd | ||
# | ||
# setup.sh is standalone (IIUC upon cursory inspection) at least for debian/aarch64 + vosk purposes | ||
# setup.sh is more or less further `apt install...` + golang install + vosk install + gen chipper/source.sh... thus run this as early as possible as it is not likely to change (as much) as the source code | ||
COPY setup.sh /setup.sh | ||
# PRN part of what setup.sh does is to install golang and other deps... why not extract those deps here for the Dockerfile and not use setup.sh inside the container build? AND why not find a golang base image to build on top of instead of installing it here? | ||
RUN dos2unix /setup.sh && mkdir /chipper && mkdir /vector-cloud | ||
RUN ["/bin/sh", "-c", "STT=vosk IMAGE_BUILD=true SETUP_STAGE=getPackages ./setup.sh"] | ||
|
||
RUN chmod +x /setup.sh && apt-get update && apt-get install -y dos2unix && dos2unix /setup.sh && apt-get install -y avahi-daemon avahi-autoipd | ||
# so we can install go deps (IIUC for vosk install in setup.sh/getSTT) | ||
COPY ./chipper/go.sum ./chipper/go.mod /chipper/ | ||
# FYI setup.sh generates /chipper/source.sh which sets env vars only | ||
RUN ["/bin/sh", "-c", "STT=vosk IMAGE_BUILD=true SETUP_STAGE=getSTT ./setup.sh"] | ||
# *** END PACKAGE INSTALLS *** | ||
|
||
RUN ["/bin/sh", "-c", "STT=vosk ./setup.sh"] | ||
# *** go download deps *** | ||
# | ||
# PRN build + cache deps: # RUN --mount=type=cache,target=/root/go/pkg/mod cd /chipper && go mod download | ||
# | ||
COPY ./vector-cloud/go.sum ./vector-cloud/go.mod /vector-cloud/ | ||
RUN cd /chipper && go mod download | ||
# vector-cloud deps are normally downloaded after initial web server Submit Settings page: | ||
RUN cd /vector-cloud && go mod download | ||
# PRN IIUC vector-cloud has some vosk model download/setup, can I add it to this image build too? | ||
# Downloading https://github.com/kercre123/vosk-models/raw/main/vosk-model-small-en-us-0.15.zip to /tmp/vosk-model-small-en-us-0.15.zip | ||
# *** END go download deps *** | ||
|
||
RUN chmod +x /chipper/start.sh && dos2unix /chipper/start.sh | ||
# PRN copy specific files only: # COPY chipper images vector-cloud / | ||
COPY . . | ||
RUN dos2unix /chipper/start.sh | ||
# TODO do we really need dos2unix? can't we use editorconfig or something else to enforce line endings? and/or force git checkout to have LF endings always? SAME with setup.sh above too | ||
# | ||
# build chipper during image build: | ||
# reuse start.sh so we keep logic for changing env vars (i.e. for whipser instead of vosk) | ||
RUN ["/bin/sh", "-c", "DO_GO_BUILD=true ./chipper/start.sh"] | ||
# PRN build vector-cloud during image build too? | ||
# PRN use multi-stage build - with builder image (w/ cached modules) separate of runtime image (final executables only)? | ||
|
||
CMD ["/bin/sh", "-c", "./chipper/start.sh"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.