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
The generic DockerContainer("ollama/ollama:latest") approach is not sufficient due to several reasons:
Complicated setup/configuration: Ollama can run with GPU acceleration inside Docker containers for Nvidia GPUs. It's important to be able to check the availability of GPUs and run the container with some if possible.
Model management: There is also the need to pull a model and commit container changes into an image after pulling a model. So that the image containing the model can be reused later.
I asked myself the same question but as it's implemented with commit in the java and typescript versions I thought it's maybe because it's simpler and more robust to implement with commit.
Using commit, you don't need to identify all the files generated by ollama to make the volume binding where using volume you should specify all the needed files. The Ollama PATH is /root/.ollama but is there another locations affected by the pull of a model? I don't know, so having the doubt, the commit approach looks safer.
Plus, the commit approach ensures that the test environment is completely self-contained within the Docker image, which can be beneficial for reproducibility and portability across different test environments I guess?
I have also realized that this is a more general concern which would also apply to java implementation. Looking at the various available images for ollama as well. one theory is that sizes vary based on number of gpu drivers available, so macos build is quite small - but then using this image on a mac would be different, so thinking about how to test this as well... this may be one of those images that only works on a linux machine, which may be okay.
Activity
alexanderankin commentedon Jun 26, 2024
does it make sense to mount a volume instead of/as well as committing a container?
bricefotzo commentedon Jun 27, 2024
@alexanderankin you raise a good point!
I asked myself the same question but as it's implemented with commit in the java and typescript versions I thought it's maybe because it's simpler and more robust to implement with commit.
Using commit, you don't need to identify all the files generated by ollama to make the volume binding where using volume you should specify all the needed files. The Ollama PATH is
/root/.ollamabut is there another locations affected by the pull of a model? I don't know, so having the doubt, the commit approach looks safer.Plus, the commit approach ensures that the test environment is completely self-contained within the Docker image, which can be beneficial for reproducibility and portability across different test environments I guess?
I think @ilopezluna or @eddumelendez have a better answer to your question
alexanderankin commentedon Jun 27, 2024
I have also realized that this is a more general concern which would also apply to java implementation. Looking at the various available images for ollama as well. one theory is that sizes vary based on number of gpu drivers available, so macos build is quite small - but then using this image on a mac would be different, so thinking about how to test this as well... this may be one of those images that only works on a linux machine, which may be okay.
alexanderankin commentedon Jun 27, 2024
I added an ollama_dir option, which maybe should have been named ollama_home or something but it does seem to work (there is a test as well)
bricefotzo commentedon Jun 27, 2024
Nice idea, so that both are possible! Thanks @alexanderankin ! Can't wait to try
alexanderankin commentedon Jun 27, 2024
why wait:
script.py:feat(core): Add support for ollama module (testcontainers#618)