Improvements to docker #81
Open
+358
−0
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hi @StevePotter thanks for your great suggestion, this seems very useful! I still need to find a time to test this myself as I'm swamped with other projects now. To be backward compatible, would you mind creating a separate |
|
Okay great, I will do that |
…ing Docker that could replace the existing one
StevePotter
force-pushed
the
docker-changes
branch
from
bb3d6a7
to
b62e455
Compare
|
I got a little sidetracked, but will devote some time to this next week. I also plan the following improvements:
|
|
Hi! I was trying this method, and I ran into an issue where the line cd /foundationpose/mycpp/ failed because it couldn't find the directory. I was wondering if this could because I placed the docker-compose file in a different location than intended; I currently place it as a subdirectory inside of main. |
|
@EquilibriaW you are right. somehow I messed it up. I'll fix |
|
Hey @StevePotter, I've tried to run your |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello friends, thank you for building such a wonderful project. I noticed a few non-standard uses of Docker and this PR provides some suggested improvements. I don't recommend merging it until there has been discussion and testing by the team.
The current dockerfile does the work of preparing the container for developing the code. None of the commands in the dockerfile touch any of the FoundationPose code. Then,
run_container.shmounts a bunch of volumes, which in turn gives the container access to the code. Since some other things still need to happen,build_all.shneeds to be run.Normally, a docker image is rather complete and all someone needs to run the code is pull the image. That's not the case here. These extra steps require more work to set up, and make it very difficult to simply deploy the FP image to a server.
Luckily, docker has some other approaches that are widely accepted. For development time, when you want to share files with the container, there is Docker Compose. Docker compose makes it easy to set up networks, mount volumes, and just about everything else that
run_container.shwas doing. Plus since the volumes are available to everyRUNcommand, everything inbuild_all.shcan be moved to the dockerfile.So now instead of
run_container.sh, you can simply use the nativedocker compose upcommand!For use in servers, docker provides a
COPYcommand that can place files from the project into the container. So, I added a second dockerfile for that,dockerfile.prod. If you build that image, it'll include everything from the git repo in the container and will run all the commands frombuild_all.sh. Then this image can quickly run anywhere, without requiring the git repo code. You could even create a Github Action that will automatically publish this image whenever an PR is merged.I'd love to hear people's thoughts on this. I'm not a FoundationPose developer and I realize you have a workflow, but I've been using docker for 10 years, and I thought I could share some of my experience. If you switch to Docker Compose, things will become easier and experiences will be more consistent across developers. Having a 2nd dockerfile may seem weird, but actually a lot of people do it.
If you think this is too much to do all at once, I can keep the old dockerfile,
run_container.sh,build_all.shand present this new way as an alternative. If and once it's determined Compose is easier, then you can remove those files later.Also, it could be possible to make a much lightweight container, which is safer and easier to deploy. There are quite a bit of build tools (g++, gcc, build-essential, cmake, etc) that could be removed from the final container if we took advantage of Docker's Multi-Stage Builds. This allows you to have multiple
FROMstatements in your dockerfile. You can use some of them to build code, then you simply copy the built cover over to the final container. I could certainly help with this if you're interested.Thanks, I hope you like this. Have a great day!