Skip to content
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

Merged
merged 1 commit into from
Mar 16, 2020
Merged

Enhanced Dockerfile with Multi Staged Build #171

merged 1 commit into from
Mar 16, 2020

Conversation

yarncraft
Copy link
Contributor

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.

You can navigate through the runtime of the container (after the build step) with:
docker run -it --entrypoint /bin/bash openspiel

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
@lanctot
Copy link
Collaborator

lanctot commented Mar 15, 2020

Hi @yarncraft, could you also update the docs/install.md to reflect the new choices and commands?

@lanctot
Copy link
Collaborator

lanctot commented Mar 16, 2020

Hi @yarncraft, could you also update the docs/install.md to reflect the new choices and commands?

Nevermind, I'll add it on the import now.

@lanctot
Copy link
Collaborator

lanctot commented Mar 16, 2020

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 COPY --from=base?

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.

@yarncraft
Copy link
Contributor Author

yarncraft commented Mar 16, 2020

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 COPY --from=base?

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).

@yarncraft
Copy link
Contributor Author

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/.

@lanctot
Copy link
Collaborator

lanctot commented Mar 16, 2020

I see, but are we guaranteed that the target FROM python:3.6-slim-buster as python-slim is still an Ubuntu 18.04 machine (but just with less stuff)?

@yarncraft
Copy link
Contributor Author

I see, but are we guaranteed that the target FROM python:3.6-slim-buster as python-slim is still an Ubuntu 18.04 machine (but just with less stuff)?

Buster is the codename for Debian 10 if I'm not mistaken

@lanctot
Copy link
Collaborator

lanctot commented Mar 16, 2020

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?

@yarncraft
Copy link
Contributor Author

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

@lanctot
Copy link
Collaborator

lanctot commented Mar 16, 2020

Ok, great. I'm fine to merge this, but would like to know that you've tested and run it :)

@yarncraft
Copy link
Contributor Author

Schermafbeelding 2020-03-16 om 19 05 16

So as you can see, Docker just completed the 29 steps for the python-slim image and running the matrix example works as expected!

@OpenSpiel OpenSpiel merged commit f811002 into google-deepmind:master Mar 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants