使用 docker-compose 安装时，支持 dind 的 Docker 容器内的 Minikube 失败

Question

我正在尝试创建一个支持 DevOps（通过 GitLab 集群代理）和 GitOps（通过 FluxCD）的 Minikube 映像。我对所有技术都有一些经验，但将它们全部整合到一个小型自动化包中似乎很困难。我正在寻找尽可能多的自动化。

为了保持图像较小，一旦图像加载到容器内，

minikube start

等就会完成。通过类似于以下的脚本完成了很多工作（正在进行中！）：

#!/bin/bash
echo "Setting up environment"
echo "Activating bash autocomplete"
echo "source /etc/profile.d/bash_completion.sh" >> ~/.bashrc
echo 'Adding alias for "minikube kubectl" as "kubectl"'
echo 'alias kubectl="minikube kubectl"' >> ~/.bashrc
echo "Installing kubectl via minikube and activating bash completion for it"
minikube kubectl completion bash >> ~/.bashrc
echo "Activating bash completion for flux"
flux completion bash > ~/flux_completion.sh
echo "source flux_completion.sh" >> ~/.bashrc
echo "Installing Minikube Kubernetes flavor with Docker driver and starting it"
echo "Adding support for Helm"
curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get-helm-3 > get_helm.sh
chmod 700 get_helm.sh
./get_helm.sh

minikube delete && minikube start --force --driver=docker

我正在通过

docker-compose

加载并设置所有内容：

version: '2'

services:
  minikube-otg:
    image: minikube-otg:latest
    container_name: minikube-otg
    restart: always
    network_mode: host
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock
  minikube-otg-setup:
    image: minikube-otg:latest
    depends_on:
      - minikube-otg
    restart: "no"
    command: bash -c "./startup.sh"

如果我只是使用

bash

以交互模式进入容器并自己执行脚本，它就可以工作。

Setting up environment
Activating bash autocomplete
Adding alias for "minikube kubectl" as "kubectl"
Installing kubectl via minikube and activating bash completion for it
Activating bash completion for flux
Installing Minikube Kubernetes flavor with Docker driver and starting it
Adding support for Helm
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 11679  100 11679    0     0   173k      0 --:--:-- --:--:-- --:--:--  175k
Downloading https://get.helm.sh/helm-v3.14.0-linux-amd64.tar.gz
Verifying checksum... Done.
Preparing to install helm into /usr/local/bin
helm installed into /usr/local/bin/helm
! "minikube" profile does not exist, trying anyways.
X Failed to stop ssh-agent process: failed loading config: cluster "minikube" does not exist
* Removed all traces of the "minikube" cluster.
* minikube v1.32.0 on Debian 12.4 (docker/amd64)
! minikube skips various validations when --force is supplied; this may lead to unexpected behavior
* Using the docker driver based on user configuration
* The "docker" driver should not be used with root privileges. If you wish to continue as root, use --force.
* If you are running minikube within a VM, consider using --driver=none:
*   https://minikube.sigs.k8s.io/docs/reference/drivers/none/
* Using Docker driver with root privileges
* Starting control plane node minikube in cluster minikube
* Pulling base image ...
* Downloading Kubernetes v1.28.3 preload ...
    > preloaded-images-k8s-v18-v1...:  403.35 MiB / 403.35 MiB  100.00% 1.92 Mi
* Creating docker container (CPUs=2, Memory=7900MB) ...
* Preparing Kubernetes v1.28.3 on Docker 24.0.7 ...
  - Generating certificates and keys ...
  - Booting up control plane ...
  - Configuring RBAC rules ...
* Configuring bridge CNI (Container Networking Interface) ...
  - Using image gcr.io/k8s-minikube/storage-provisioner:v5
* Verifying Kubernetes components...
* Enabled addons: default-storageclass, storage-provisioner
* Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

在单独的步骤中安装并重新注册（相同令牌）我的 GitLab 代理后，我得到了我所期望的：

但是，问题是如果通过

docker-compose

完成此设置，则无法安装 Minikube。我收到以下错误：

minikube-otg-setup_1  | ! "minikube" profile does not exist, trying anyways.
minikube-otg-setup_1  | X Failed to stop ssh-agent process: failed loading config: cluster "minikube" does not exist
minikube-otg-setup_1  | * Removed all traces of the "minikube" cluster.
minikube-otg-setup_1  | * minikube v1.32.0 on Debian 12.4 (docker/amd64)
minikube-otg-setup_1  | ! minikube skips various validations when --force is supplied; this may lead to unexpected behavior
minikube-otg-setup_1  | * Using the docker driver based on user configuration
minikube-otg-setup_1  | 
minikube-otg-setup_1  | X "docker version --format {{.Server.Os}}-{{.Server.Version}}:{{.Server.Platform.Name}}" exit status 1: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
minikube-otg-setup_1  | * Suggestion: Start the Docker service
minikube-otg-setup_1  | * Documentation: https://minikube.sigs.k8s.io/docs/drivers/docker/
minikube-otg-setup_1  | 
minikube-otg-setup_1  | 
minikube-otg-setup_1  | X Exiting due to MK_USAGE: Ensure your Docker is running and is healthy.

我脚上的刺是错误

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

但是，正如您从我的 YML 配置中看到的，

docker.sock

应该被暴露。

我的研究表明，这与第二个服务启动时（调用安装 Minikube 的脚本）时容器的特定设施尚未启动有关。第二个服务也有一个

depends_on

参数，但我想它对我没有任何好处，因为 Docker 确实将第一个服务报告为健康且正在运行，因此为什么第二个服务立即启动（可能在启动后 1 秒左右）第一个：D）。那么我可能又错了。如果我可以提供更多信息，请告诉我。

Answer 1

问题似乎与在 Docker Compose 配置中启动第二个服务时 Docker 守护进程的可用性时间有关。您可以考虑这些方法来解决问题；

1. 添加健康检查。您可以为第二个服务添加健康检查，以确保 Docker 守护进程在启动脚本执行之前可用。这可以通过创建一个自定义运行状况检查脚本来验证 Docker 守护程序的可用性并在 Docker Compose 文件中对其进行配置来实现。

2. 延迟启动。您可以在第二个服务的启动中引入延迟，以允许 Docker 守护进程变得可用。这可以通过在第二个服务的启动脚本中使用简单的 sleep 命令来实现。

以下是如何使用 sleep 命令在第二个服务的启动中引入延迟的示例：

version: '2'

services:
  minikube-otg:
    image: minikube-otg:latest
    container_name: minikube-otg
    restart: always
    network_mode: host
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock
  minikube-otg-setup:
    image: minikube-otg:latest
    depends_on:
      - minikube-otg
    restart: "no"
    command: bash -c "sleep 10 && ./startup.sh"