代码之家  ›  专栏  ›  技术社区  ›  hotmeatballsoup

为Docker Compose设置绑定挂载卷的条件

  •  0
  • hotmeatballsoup  · 技术社区  · 5 年前

    请注意: 我的问题提到了MySQL,但本质上这是一个Docker/Docker Compose卷管理问题,因此,任何在该领域有丰富经验的人都应该回答,无论他们是否熟悉MySQL。


    我的 理解力 是Docker化MySQL容器,当从Docker Compose文件中定义时,如下所示 短暂的 ,这意味着它们将所有数据存储在容器本身上(没有绑定挂载等),因此当容器死亡时,数据也会消失:

    version: "3.7"
    services:
      my-service-db:
        image: mysql:8
        container_name: $MY_SERVICE_DB_HOST
        command: --default-authentication-plugin=mysql_native_password
        restart: always
        ports:
          - $MY_SERVICE_DB_PORT:$MY_SERVICE_DB_PORT
        environment:
          MYSQL_ROOT_PASSWORD: $MY_SERVICE_DB_ROOT_PASSWORD
          MYSQL_DATABASE: my_service_db_$MY_ENV
          MYSQL_USER: $MY_SERVICE_DB_APP_USER
          MYSQL_PASSWORD: $MY_SERVICE_DB_APP_PASSWORD
      other-service-definitions-omitted-for-brevity:
        - etc.
    

    首先,如果这种理解是 不正确的 ,请先纠正我!假设它或多或少是正确的。。。

    让我们称之为 短暂模式 .

    但是,通过为该服务定义提供绑定装载卷,我们可以指定一个存储数据的外部位置,因此数据将在服务运行过程中持续存在(组成上升/下降):

    version: "3.7"
    services:
      my-service-db:
        image: mysql:8
        container_name: $MY_SERVICE_DB_HOST
        command: --default-authentication-plugin=mysql_native_password
        restart: always
        ports:
          - $MY_SERVICE_DB_PORT:$MY_SERVICE_DB_PORT
        environment:
          MYSQL_ROOT_PASSWORD: $MY_SERVICE_DB_ROOT_PASSWORD
          MYSQL_DATABASE: my_service_db_$MY_ENV
          MYSQL_USER: $MY_SERVICE_DB_APP_USER
          MYSQL_PASSWORD: $MY_SERVICE_DB_APP_PASSWORD
        volumes:
          - ./my-service-db-data:/var/lib/mysql
      other-service-definitions-omitted-for-brevity:
        - etc.
    

    让我们称之为 持久模式 .

    有时我想在中运行我的Docker Compose文件 短暂模式 ,其他时候,运行它 持久模式 .

    是否有可能使 volumes 定义(在Docker Compose文件中)有什么条件?所以有时候我可以跑步 docker-compose up -d <SPECIFY_EPHEMERAL_MODE_SOMEHOW> ,其他时候我可以跑步 docker-compose up -d <SPECIFY_PERSISTENT_MODE_SOMEHOW> ?

    0 回复  |  直到 5 年前
        1
  •  1
  •   David Maze    5 年前

    你可以拥有 multiple Compose files 它们协同工作,其中您有一些基本文件,然后是扩展基本文件中定义的其他文件。

    无需额外设置,Compose会寻找 docker-compose.override.yml 在主旁边 docker-compose.yml 。因为“短暂”和“持久”模式之间的唯一区别是 volumes: 声明中,您可以有一个只包含以下内容的覆盖文件:

    # docker-compose.override.yml
    version: '3.8'
    services:
      my-service-db:  # matches main docker-compose.yml
        volumes:      # added to base definition
          - ./my-service-db-data:/var/lib/mysql
    

    您还可以使用此技术将实际的数据库凭据和端口发布从主文件移至特定于部署的配置中。对于需要在生产中运行已知的Docker镜像但在开发中构建它的设置,以及用主机目录覆盖容器内容的设置,使用它也是很常见的。

    如果你想让文件命名为其他名称,你可以,但你需要始终如一地提供 docker-compose -f 选项或设置 COMPOSE_FILE environment variable 每次你跑Compose。

    docker-compose -f docker-compose.yml -f docker-compose.persistence.yml up -d
    docker-compose -f docker-compose.yml -f docker-compose.persistence.yml ps
    docker-compose -f docker-compose.yml -f docker-compose.persistence.yml logs app
    
    # Slightly easier (Linux syntax):
    export COMPOSE_FILE=docker-compose.yml:docker-compose.persistence.yml
    docker-compose up -d
    

    从哲学上讲,应用程序的数据需要持久化 在某处 。对于应用程序容器,一个好的做法是让它们完全无状态(它们不会挂载 体积: )并将所有数据推送到数据库中。这意味着数据库需要持久化数据,否则在数据库重新启动时会丢失数据。

    IME主动希望数据库丢失数据有点不寻常。如果使用种子数据直接创建数据库映像会更有趣,但标准映像的构建方式会使这变得困难。在测试环境中,我仍然可以看到它的存在。

    实际上,构建一个在Docker中运行但使用外部数据库的应用程序是可能的,也是合理的。也许你在云环境中运行,你的云提供商有一个稍微昂贵的托管数据库服务,例如提供自动快照和故障转移;您可以将生产应用程序配置为使用此托管数据库,而在容器中根本不保留任何数据。

    推荐文章