-
Notifications
You must be signed in to change notification settings - Fork 950
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
Enhanced Dockerfile with Multi Staged Build #171
Conversation
Option to choose final runtime: - Base (3.13GB) = docker build --target base -t openspiel . --rm - Slim (2.26GB) = docker build --target python-slim -t openspiel . --rm The second image serves for development in Python
Hi @yarncraft, could you also update the |
Nevermind, I'll add it on the import now. |
Hold on... @yarncraft , there's something I don't understand. Why is the second one smaller? It seems to require everything the first one uses, doesn't it? Using Either that.... or it doesn't build OpenSpiel at all, which will not work. The Python API depends on the base OpenSpiel being built. So one of these needs to be fixed. |
Ok so this is exactly the purpose of having a multi-stage build in Docker. We use the base image in Ubuntu in order to compile everything. Finally we move these files to a new runtime which runs in fact on a smaller OS (more info: https://pythonspeed.com/articles/base-image-python-docker-images/). As commented in the Dockerfile itself, the second stage should solely be used in order to run python examples and scripts (not their C++ counterparts). |
Now the fun thing with multi-stage builds is that you can select your target! So in a CICD setup you can for example build two distinct images (a full blown runtime and a reduced one) by just having to change the target stage! You can learn more about Docker in this free guide: https://docker-curriculum.com/. |
I see, but are we guaranteed that the target |
Buster is the codename for Debian 10 if I'm not mistaken |
I don't understand how that could work.. the binaries built would be dynamically linking to certain libs, and they may not have the same versions on Debian 10 and so not found? I guess it might work because Debian and Ubuntu are so similar. Did you test it? It runs the python examples? |
Never thought about that, but since there are many blog posts writing about how to reduce image sizes (such as https://blog.realkinetic.com/building-minimal-docker-containers-for-python-applications-37d0272c52f3) I think it does not matter since you'll be installing the same requirements.txt (with versioning constraints) on the new OS. I am rebuilding now to show you an example |
Ok, great. I'm fine to merge this, but would like to know that you've tested and run it :) |
Option to choose final runtime:
docker build --target base -t openspiel . --rm
docker build --target python-slim -t openspiel . --rm
The second image serves for development in Python.
You can navigate through the runtime of the container (after the build step) with:
docker run -it --entrypoint /bin/bash openspiel