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

whalebrew in whalebrew #36

Open
colltoaction opened this issue Feb 2, 2017 · 2 comments
Open

whalebrew in whalebrew #36

colltoaction opened this issue Feb 2, 2017 · 2 comments

Comments

@colltoaction
Copy link

colltoaction commented Feb 2, 2017

If whalebrew enabled docker in docker (see #24), and also installed itself in all containers, then you could have your tools talk to each other!

Goal: my whalebrew packages can call each other.

Example: when you build with microsoft/dotnet you might want to call node or npm to do run frontend tasks.

Benefits:

  • Each tool is downloaded as needed (e.g. docker run downloads what it needs)
  • Using official images gives you faster updates and well-tested tools
  • Your environment is now composable, and updating or adding a tool automatically updates your whole environment
  • You can run complicated tools in any Linux distro (e.g. installing and running dotnet in Arch Linux is a nightmare)

Let me know what you think or if you think it's not possible!

Thanks!

@tjamet
Copy link
Contributor

tjamet commented Mar 12, 2019

Hi,
Thanks for the suggestion. I tend to think this is quite possible. Although, I have a concern regarding the security of such a feature.

To allow commands to call one another we would need to run somehow whalebrew run, and hence need to bind the docker socket for each command.

This means that any command could then be able to execute roughly anything the docker API allows, including binding host volumes, runnning privileged containers ..., and hence exposing undesired data.
Being able to control what a given command can do is, for me, one of the great advantage of whalebrew, enforced by #24

This means we need to encounter a simple way to do so without providing this whole uncontrolled access

tjamet added a commit that referenced this issue Mar 16, 2019
Make use of multi stage builds to produce smaller output image
Tune the dockerignore to reduce the context size sent to docker and hence improve build speed
Make use of go modules cache to not re-download everything when only the code is changed

This produces a small output image, a first step towards #36 and #32

fixes #72
tjamet added a commit that referenced this issue Mar 16, 2019
Make use of multi stage builds to produce smaller output image
Tune the dockerignore to reduce the context size sent to docker and hence improve build speed
Make use of go modules cache to not re-download everything when only the code is changed

This produces a small output image, a first step towards #36 and #32

fixes #72
tjamet added a commit that referenced this issue Apr 18, 2019
Rework Dockerfile to provide a minimal image.
This image can then easily be ran through
`docker run --rm -v<PathToExecutable>:/executable -v /var/run/docker.sock:/var/run/docker.sock whalebrew/whalebrew /executable <args>`

fixes #32

A step forward for #36
tjamet added a commit that referenced this issue Apr 18, 2019
Rework Dockerfile to provide a minimal image.
This image can then easily be ran through
`docker run --rm -v<PathToExecutable>:/executable -v /var/run/docker.sock:/var/run/docker.sock whalebrew/whalebrew /executable <args>`

fixes #32

A step forward for #36
@tjamet
Copy link
Contributor

tjamet commented Apr 20, 2019

I have been thinking about this issue lately and here is what I came with

Declare dependencies

Introduce a way to declare that an image depends on external commands (like io.whalebrew.config.depends="["git"]")

expose a whalebrew-in-whalebrew command

When Whalebrew starts a container, if this container has dependencies, it mounts a runnable whalebrew-in-whalebrew command (benefiting the --volumes-from option?)
this whalebrew-in-whalebrew should forward the execution to Whalebrew which will then execute the command. Communication between w-in-w and Whalebrew to be thought (unix/http socket?)

The setup is not that simple but copes well with security ensuring that the docker socket, providing root privileges, is not exposed to user land programs.

tjamet added a commit that referenced this issue Apr 24, 2019
Rework Dockerfile to provide a minimal image.
This image can then easily be ran through
`docker run --rm -v<PathToExecutable>:/executable -v /var/run/docker.sock:/var/run/docker.sock whalebrew/whalebrew /executable <args>`

fixes #32

A step forward for #36
tjamet added a commit that referenced this issue May 11, 2019
Rework Dockerfile to provide a minimal image.
This image can then easily be ran through
`docker run --rm -v<PathToExecutable>:/executable -v /var/run/docker.sock:/var/run/docker.sock whalebrew/whalebrew /executable <args>`

fixes #32

A step forward for #36
tjamet added a commit that referenced this issue May 11, 2019
Rework Dockerfile to provide a minimal image.
This image can then easily be ran through
`docker run --rm -v<PathToExecutable>:/executable -v /var/run/docker.sock:/var/run/docker.sock whalebrew/whalebrew /executable <args>`

fixes #32

A step forward for #36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants