What does minikube docker-env mean?

Try to run minikube docker-env

You will see some environment variables are mentioned there :)

These variables will help your docker CLI (where you write docker commands) to connect with docker daemon in the VM created by minikube !

Now, to connect your Docker CLI to the docker daemon inside the VM you need to run : eval $(minikube docker-env)

This will temporarily(for that terminal) connect CLI to docker daemon inside the VM :)

Now, try to do docker ps , you can see all the containers created inside the VM (will be shown only if you have done some work in k8's cluster)

This is all possible due to those environment variables by docker-env

One way to figure out what $ eval $(minikube docker-env) does is to understand that we want to build a docker image in our local machine and then deploy them to the minikube environment. This command as others have explained makes it easier to do so.

  • It is telling minikube to use the configs returned from minikube docker-env
  • You can then build your docker image locally and be able to access it within the minikube env
  • Once you're done building you can unset docker env i.e. disconnect your minikube env by unsetting these docker configs if you run minikube docker-env --unset

Without setting your docker configs to minikube env it'll be a bit tedious to build your image locally and run it in a container in your minikube env.

If you have minikube running you can ssh into the env and see all docker images running within it.

The command minikube docker-env returns a set of Bash environment variable exports to configure your local environment to re-use the Docker daemon inside the Minikube instance.

Passing this output through eval causes bash to evaluate these exports and put them into effect.

You can review the specific commands which will be executed in your shell by omitting the evaluation step and running minikube docker-env directly. However, this will not perform the configuration – the output needs to be evaluated for that.

This is a workflow optimization intended to improve your experience with building and running Docker images which you can run inside the minikube environment. It is not mandatory that you re-use minikube's Docker daemon to use minikube effectively, but doing so will significantly improve the speed of your code-build-test cycle.

In a normal workflow, you would have a separate Docker registry on your host machine to that in minikube, which necessitates the following process to build and run a Docker image inside minikube:

  1. Build the Docker image on the host machine.
  2. Re-tag the built image in your local machine's image registry with a remote registry or that of the minikube instance.
  3. Push the image to the remote registry or minikube.
  4. (If using a remote registry) Configure minikube with the appropriate permissions to pull images from the registry.
  5. Set up your deployment in minikube to use the image.

By re-using the Docker registry inside Minikube, this becomes:

  1. Build the Docker image using Minikube's Docker instance. This pushes the image to Minikube's Docker registry.
  2. Set up your deployment in minikube to use the image.

More details of the purpose can be found in the minikube docs.