On local environment, use spanner's docker emulator to create development tools.
If use minikube, run its docker in kubernetes environment, can start its container
minikube start
eval $(minikube docker-env)
docker run -p 9010:9010 -p 9020:9020 gcr.io/cloud-spanner-emulator/emulator
But can't create an instance via gcloud command
gcloud spanner instances create test-env --config=emulator-config --description="Local dev instance" --nodes=1
It became pending.
When use an environment without minikube, I can start docker and create an instance
docker run -p 9010:9010 -p 9020:9020 gcr.io/cloud-spanner-emulator/emulator
gcloud spanner instances create test-env --config=emulator-config --description="Local dev instance" --nodes=1
gcloud spanner instances list
It seems can't run gcloud spanner command under minikube's docker-env. Why?
Doing eval $(minikube docker-env) configures environment to use minikube’s Docker daemon (https://minikube.sigs.k8s.io/docs/commands/docker-env/).
Thus, emulator is running "inside" the docker domain that is running "inside" the minikube cluster.
You can verify the same by sshing into the minikube cluster using ssh minikube to see the list of running processes. You can then do a curl on http://localhost:9020/v1/projects/test-project/instances, which should return a result immediately.
This seems likely due to the port not being exposed.
By default, minikube only exposes ports 30000-32767. You can change that with the following:
minikube start --extra-config=apiserver.service-node-port-range=1-65535
https://minikube.sigs.k8s.io/docs/handbook/accessing/#increasing-the-nodeport-range
Related
I've set up the Docker Engine locally to run on minikube (rather than using Docker Desktop). I know that I need to make sure that the Engine "talks to" the minikube cluster. I've consulted two tutorials, which have slightly different instructions. Specifically for this question, I want to understand the difference between the command:
eval $(minikube -p minikube docker-env)
referenced here, and
eval $(minikube docker-env)
referenced here. What does the profile flag -p do in this case?
Minikube profiles are a way of getting different isolated environments (VMs), which can be helpful in a handful of scenarios (testing how the application behaves on different networks, testing different K8s versions, etc).
By default, the minikube start will start a VM with a profile named minikube that can be referenced through -p minikube or --profile minikube or simply by omitting the profile. So in practice minikube -p minikube docker-env and minikube docker-env are the same command, but minikube -p otherkube docker-env points to a different profile.
The command minikube -p <profile> docker-env prints out a set of environment variables that when evaluated will allow your local docker commands to point to the docker agent inside the specified profile's VM. The eval command will run these exports in the current shell. Setting different profiles will change slightly some of the variables (namely the docker host and the active docker daemon VM).
The minikube -p <profile> docker-env will fail if the specified profile is stopped. In the same way, minikube docker-env will fail if the minikube profile is stopped.
You can get a list of existing profiles using the following command:
minikube profile list
You can run the following commands to better understand the difference between the output when using different profiles.
minikube -p minikube start
minikube -p otherkube start
minikube docker-env
minikube -p minikube docker-env
minikube -p otherkube docker-env
It's possible to run more than one minikube cluster at a time. From the minikube FAQ:
By default, minikube start creates a cluster named “minikube”. If you would like to create a different cluster or change its name, you can use the --profile (or -p) flag, which will create a cluster with the specified name. Please note that you can have multiple clusters on the same machine.
So the minikube -p minikube option is just explicitly naming the default minikube cluster. If you're only running one (probably the common case) it's safe to omit it.
With both of these commands, you also might try just running the commands, without evaluating their output
minikube docker-env
minikube -p minikube docker-env
and see what shell commands they generate. (They're probably extremely similar.)
I want to use Visual-Studio-Code to bind onto a container, that is running on the Docker instance inside Minikube.
The Docker extension by default binds to the Docker instance running on localhost, rather than then Docker instance running inside minikube.
In a shell I'd just do:
eval $(minikube -p minikube docker-env)
so my docker .. commands would execute inside Minikube.
But how can I tell VSCode to pre-run the docker-env command?
Or how can I tell VSCode where the Minikube Docker instance is? I don't seem to find any setting.
There is a plugin available called Bridge to Kubernetes using this plugin you can iteratively run and debug containers directly in MiniKube, Azure Kubernetes Service (AKS), or another Kubernetes provider, you have to install this plugin and make necessary configurations for playing with your containers on minikube.
I have installed minikube and started it with it's default virtual machine so basically started the minikube with minikube start. In minikube vm which i have accessed through minikube ssh i am trying to build my dockerfile after mounting the local file system but it's showing error Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
I checked the ActiveState of docker through systemctl show --property ActiveState docker and it's showing failed but the docker version is showing me all the normal details like version built etc.
This is the statement that i am trying to execute : $ sudo docker build --file=Dockerfile --tag=demo-backend:latest --rm=true .
Should i install docker seperatley and if not how should access docker in VM which is already present in my system
It looks like somehow docker has not started properly.
Please try to execute sudo systemctl start docker and let me know if that was the issue.
EDIT:
Adding more info from the comments in order to supplement the answer:
I had to set the docker environment variable to local instance of
docker running in minikube through this command: eval $(minikube
docker-env) and then restart the docker and all of this has to done in
the same shell in which i aim to access the docker otherwise it does
not works. this made me acces the docker from minikube – rehan
I have deployed my application via docker on Google Kubernetes cluster. I am facing an application error due to which I want to enter inside the container and check a few things. At local, all I had to do was run sudo docker ps and then exec -it into the container.
How can I do that when containers are deployed on a Kubernetes cluster?
You need to use kubectl
kubectl get pods
kubectl exec -it pod-container-name -- /bin/bash
In the Kubernetes minikube tutorial there is this command to use Minikube Docker daemon :
$ eval $(minikube docker-env)
What exactly does this command do, that is, what exactly does minikube docker-env mean?
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:
Build the Docker image on the host machine.
Re-tag the built image in your local machine's image registry with a remote registry or that of the minikube instance.
Push the image to the remote registry or minikube.
(If using a remote registry) Configure minikube with the appropriate permissions to pull images from the registry.
Set up your deployment in minikube to use the image.
By re-using the Docker registry inside Minikube, this becomes:
Build the Docker image using Minikube's Docker instance. This pushes the image to Minikube's Docker registry.
Set up your deployment in minikube to use the image.
More details of the purpose can be found in the minikube docs.
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.
You should run this command after running 'minikube start'
eval $(minikube docker-env) this command let you Connect your cli tool to docker-env of Kubernetes cluster