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

Machine should configure Docker to automatically control the active machine #16

Closed
bfirsh opened this Issue Dec 5, 2014 · 14 comments

Comments

Projects
None yet
7 participants
@bfirsh
Contributor

bfirsh commented Dec 5, 2014

We should configure the Docker host and authentication method so this works seamlessly:

$ machine create -d virtualbox dev
$ docker run ...

The best way to do this is probably to create a configuration file that sets these options (~/.docker/config?). This will require modification to Docker – I'll put together a proposal on the Docker repository.

An alternative method could be to set environment variables. For example, there could be a machine config command which output:

export DOCKER_HOST=$(machine url) DOCKER_AUTH=identity`

You could then just run $(machine config) and your shell would be set up to talk to the active machine.

@bfirsh bfirsh changed the title from Machine should configure Docker to automatically control the active host to Machine should configure Docker to automatically control the active machine Dec 5, 2014

@kaos

This comment has been minimized.

Show comment
Hide comment
@kaos

kaos Dec 5, 2014

The first option is the only viable long term option (or a similar solution, i.e. not environment based) as I see it. As otherwise machine ls will be misleading with regard to which one is currently the active one. Perhaps machine ought to look at DOCKER_HOST (or whatever other config option will be in the future) to determine the current active machine, to avoid confusion.

kaos commented Dec 5, 2014

The first option is the only viable long term option (or a similar solution, i.e. not environment based) as I see it. As otherwise machine ls will be misleading with regard to which one is currently the active one. Perhaps machine ought to look at DOCKER_HOST (or whatever other config option will be in the future) to determine the current active machine, to avoid confusion.

@bfirsh bfirsh added this to the 1.0 milestone Dec 9, 2014

@bfirsh

This comment has been minimized.

Show comment
Hide comment
@bfirsh

bfirsh Dec 12, 2014

Contributor

Here is a previous proposal about how this could work: moby/moby#7232

Contributor

bfirsh commented Dec 12, 2014

Here is a previous proposal about how this could work: moby/moby#7232

@bfirsh

This comment has been minimized.

Show comment
Hide comment
@bfirsh

bfirsh Jan 2, 2015

Contributor

Here's a comment on that proposal explaining the requirements for Machine: moby/moby#7232 (comment)

Contributor

bfirsh commented Jan 2, 2015

Here's a comment on that proposal explaining the requirements for Machine: moby/moby#7232 (comment)

@ehazlett

This comment has been minimized.

Show comment
Hide comment
@ehazlett

ehazlett Jan 2, 2015

Member

I think integration into Docker Engine would be best. However, I think to create a better user experience we should do the env vars config for the interim. This has bit me multiple times :)

Member

ehazlett commented Jan 2, 2015

I think integration into Docker Engine would be best. However, I think to create a better user experience we should do the env vars config for the interim. This has bit me multiple times :)

@sthulb

This comment has been minimized.

Show comment
Hide comment
@sthulb

sthulb Jan 2, 2015

Contributor

+1 for the env vars via machine config for now.

Contributor

sthulb commented Jan 2, 2015

+1 for the env vars via machine config for now.

@sthulb

This comment has been minimized.

Show comment
Hide comment
@sthulb

sthulb Jan 2, 2015

Contributor

However, it would perhaps be more advantageous for people to have this instead:

Zsh:

_machine_env_hook() {
  export DOCKER_HOST=$(machine url) DOCKER_AUTH=identity`
}
typeset -ag precmd_functions
if [[ -z $precmd_functions[(r)_machine_env_hook] ]]; then
  precmd_functions+=_machine_env_hook;
fi

Bash:

_machine_env_hook() {
  export DOCKER_HOST=$(machine url) DOCKER_AUTH=identity`
}
if ! [[ "$PROMPT_COMMAND" =~ _machine_env_hook ]]; then
  PROMPT_COMMAND="_machine_env_hook;$PROMPT_COMMAND";
fi

We could make machine config output that for now...

Contributor

sthulb commented Jan 2, 2015

However, it would perhaps be more advantageous for people to have this instead:

Zsh:

_machine_env_hook() {
  export DOCKER_HOST=$(machine url) DOCKER_AUTH=identity`
}
typeset -ag precmd_functions
if [[ -z $precmd_functions[(r)_machine_env_hook] ]]; then
  precmd_functions+=_machine_env_hook;
fi

Bash:

_machine_env_hook() {
  export DOCKER_HOST=$(machine url) DOCKER_AUTH=identity`
}
if ! [[ "$PROMPT_COMMAND" =~ _machine_env_hook ]]; then
  PROMPT_COMMAND="_machine_env_hook;$PROMPT_COMMAND";
fi

We could make machine config output that for now...

@bfirsh

This comment has been minimized.

Show comment
Hide comment
@bfirsh

bfirsh Jan 5, 2015

Contributor

If we're going to do machine config then I think that:

  1. it needs a better name that makes it clear that it's outputting a shell script
  2. it should just output export DOCKER_HOST=tcp://x.x.x.x:2376 DOCKER_AUTH=identity
Contributor

bfirsh commented Jan 5, 2015

If we're going to do machine config then I think that:

  1. it needs a better name that makes it clear that it's outputting a shell script
  2. it should just output export DOCKER_HOST=tcp://x.x.x.x:2376 DOCKER_AUTH=identity
@sthulb

This comment has been minimized.

Show comment
Hide comment
@sthulb

sthulb Jan 5, 2015

Contributor

@bfirsh Firstly, perhaps config-shell

Secondly, if it just outputs an export, one would have to restart their shell for it to pick it up, creating the workflow of:

  1. machine create ...
  2. exit shell
  3. reopen shell
  4. docker run ...
Contributor

sthulb commented Jan 5, 2015

@bfirsh Firstly, perhaps config-shell

Secondly, if it just outputs an export, one would have to restart their shell for it to pick it up, creating the workflow of:

  1. machine create ...
  2. exit shell
  3. reopen shell
  4. docker run ...
@bfirsh

This comment has been minimized.

Show comment
Hide comment
@bfirsh

bfirsh Jan 5, 2015

Contributor

True.

I think we should aim to get Machine to automatically configure Docker. This is a hack which can use as a last resort.

Contributor

bfirsh commented Jan 5, 2015

True.

I think we should aim to get Machine to automatically configure Docker. This is a hack which can use as a last resort.

@sthulb

This comment has been minimized.

Show comment
Hide comment
@sthulb

sthulb Jan 5, 2015

Contributor

For that, we need docker to be changed to allow for your proposal from moby/moby#7232

Contributor

sthulb commented Jan 5, 2015

For that, we need docker to be changed to allow for your proposal from moby/moby#7232

@SvenDowideit

This comment has been minimized.

Show comment
Hide comment
@SvenDowideit

SvenDowideit Jan 10, 2015

Contributor

I'd propose $(machine shellinit) only because thats what boot2docker has had, so many users are used to it.

Contributor

SvenDowideit commented Jan 10, 2015

I'd propose $(machine shellinit) only because thats what boot2docker has had, so many users are used to it.

@ehazlett

This comment has been minimized.

Show comment
Hide comment
@ehazlett

ehazlett Jan 22, 2015

Member

For now, we are using the machine config command (not shell init as it just passes args to the Docker CLI and nothing in the environment) and swarm is doing the same. The long term solution is support in the engine.

Member

ehazlett commented Jan 22, 2015

For now, we are using the machine config command (not shell init as it just passes args to the Docker CLI and nothing in the environment) and swarm is doing the same. The long term solution is support in the engine.

@ehazlett ehazlett removed this from the 0.1.0 milestone Jan 22, 2015

@ehazlett ehazlett added the waiting label Feb 26, 2015

@parabuzzle

This comment has been minimized.

Show comment
Hide comment
@parabuzzle

parabuzzle Jun 25, 2015

+1

Also, I may have created a duplicate (or augmentation) to this issue yesterday: #1416

parabuzzle commented Jun 25, 2015

+1

Also, I may have created a duplicate (or augmentation) to this issue yesterday: #1416

@nathanleclaire

This comment has been minimized.

Show comment
Hide comment
@nathanleclaire

nathanleclaire Jul 6, 2015

Contributor

I am closing this issue as I think it's "as good as it's going to get" in Machine right now and further solutions would mandate support in Docker itself.

Contributor

nathanleclaire commented Jul 6, 2015

I am closing this issue as I think it's "as good as it's going to get" in Machine right now and further solutions would mandate support in Docker itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment