主页 / 问题 / 632859
Accepted
ruslik
Asked:2020-02-27 02:18:32 +0000 UTC2020-02-27 02:18:32 +0000 UTC

使用数据库的码头工人

  • 772

问题。如何使用数据库

有这样一个conf文件——docker-compose.yml

我是否正确理解这些步骤？

  1. 我有sql文件

  2. 我将它复制到 lemp_mariadb 容器中

  3. 我在那里进行数据库导入并且一切正常？是否需要采取其他措施？

然后事实证明，为了更改结构或数据，我总是需要进入容器内部并更改那里的结构？

另一个时刻

laravel使用的，有artisan进行迁移。所以我知道结构问题会得到解决，但是可以更新的数据呢？

情况： 另一个开发人员将下载应用程序，他还需要进入容器并部署数据库？

version: '2'
    services:
      nginx:
        image: evild/alpine-nginx:1.9.15-openssl
        container_name: lemp_nginx
        restart: always
        links:
          - php
        volumes:
          - ./project:/var/www/
          - ./docker/nginx/conf/nginx.conf:/etc/nginx/conf/nginx.conf:ro
          - ./docker/nginx/conf.d:/etc/nginx/conf.d:ro
        ports:
          - 8080:80
          - 443:443
      php:
        image: evild/alpine-php:7.0.6
        working_dir: /var/www
        container_name: lemp_php
        restart: always
        volumes:
          - ./project:/var/www/
        depends_on:
          - db

        links:
          - db
        environment:
          - DB_NAME=mysql
          - DB_USER=root
          - DB_PASSWORD=password
      db:
        image: mariadb:latest
        container_name: lemp_mariadb
        restart: always
        volumes:
          - db-data:/var/lib/mysql
docker

2 个回答

  1. Best Answer

    是的，经验法则 - 结构更改（迁移）可以自动发生，所有从转储中恢复的数据都是手动完成的 - 只是因为此操作不属于正常维护操作的类别。因此，手动将转储转储到容器中确实值得（您可以简单地将数据库目录移动到主机，以免每次都这样做，或者创建一个单独的开发映像，其中包含已填充的数据库）。强制容器在启动时注入转储并在开发期间更改它不是一个好主意。

    我不认为数据库会在开发人员之间以某种方式产生分歧是一个大问题——这在理论上会导致遗漏错误，但在负责任的开发中，它不应该对正在进行的流程产生太大影响。

    然而，编程越来越多地包括种子这样的东西- 用初始数据填充数据库，这些数据保证在这个数据库中并且实际上是应用程序的一部分（例如，如果有一个从莫斯科和圣彼得堡开始的多区域应用程序，那么创建是有意义的这两个区域在应用程序初始部署期间数据库中，以便应用程序没有机会以空形式上升）。与从转储中完全恢复不同，这是一个标准的维护操作，在这种情况下，您可以创建一个单独的开发种子，其中包含开发人员需要的最少数据集，并完全自动化该过程。就 laravel 而言，这似乎是最佳策略，尽管需要付出很多努力才能使该数据集保持最新，而且很可能，

    • 2

  2. 在有状态容器上已经有相当多的副本被破坏了。特别是包含数据库的容器。

    重要的是要定义我们在这里要实现的目标。选项是：

    1. 数据库的不可变状态。有一个数据库运行时、它的配置（可能在启动时使用环境变量）、SQL (DDL) 和 SQL (DML) 以及启动时的数据。根据使用的环境变量，我们每次运行它时都会得到相同的结果。你可以测试，你可以确定这对所有开发人员都是如此。有时，您可以执行 SQL 转储并构建新版本的容器。减号：通过这种方法，我们失去了数据库状态的变化。有利于发展。
    2. 不可变的配置和模式。数据库运行时、配置和 DDL 打包在容器中并经过验证。二进制工作数据库文件（和事务日志）形式的数据通过卷连接。因此，它们不是一成不变的。我们单独处理数据。我们备份，我们提供容错。这里有一个危险：一次只有一个容器可以处理一组数据文件而没有损坏它们的风险。其他开发人员在启动容器时，必须从某个地方将他们的数据集连接到容器，这与第一个不同。对于开发来说，这不太好，但是在生产中，否则不可能保证备份正常不丢失数据。
    3. 与前面的选项不同，您可以将数据以 SQL (DML) 的形式存储在单独的容器中，并定期重建它。作为卷连接到数据库运行时。同样，在开发中，这允许您使用可重现的数据库配置（包括数据）进行操作。但与此同时，具有配置和模式的运行时以及数据分别进行版本控制。对于可重现的数据容器，每次都必须从 SQL (DML) 脚本中收集。这可能很方便：增量大小更小，例如，SQL 可以存储在 Git 中。缺点是这并不总是可能的。例如，在 Git 中存储大型数据库的转储是没有意义的：差异不会告诉您任何信息。
    4. 从销售中提交容器的当前状态作为备份的选项不被视为 Ops Smell。我们得到了某个二进制文件，目前尚不清楚它是如何获得的。不可重现，以日志等形式存储大量不必要的垃圾。或者仅仅是因为 Docker 容器文件系统的结构方式可以节省增量。

    因此，虽然该项目未在生产中启动，但第一种选择更方便。当项目已经在生产中时，通常只有选项 2 是可能的。如果 SQL (DML) 是手工仔细完成的（例如，在具有参考信息的数据库的情况下），那么在生产中您可以使用选项3的便利。

    最终，选择是我们让什么变得不可变和可版本化，以及我们让什么变得流动和“有生命力”，但不是可版本化的。

    编辑：让我们清理一些术语。

    图像是开发人员相互交换的，发送到生产环境的；从中启动容器的一些冷冻铸件。

    容器正在运行使用处理器和内存的进程，它们的状态是短暂的，在一般情况下生命不值一分钱。通过从同一个图像启动两个容器，我们将在开始时获得相同的状态。但后来每个人都过着自己的生活。

    卷（volume）——来自主机（host）文件系统的文件夹，容器将其视为其文件系统的一部分。因此，卷在容器的诞生、死亡、启动和停止后仍然存在，并存储其中发生的所有变化。卷的状态与容器的状态分开很重要。此外，卷的工作直接通过主机文件系统进行，绕过了容器文件系统层。对于密集型磁盘 IO，这会带来性能提升。卷的内容不存储在镜像中，因此不可复制（除非它是打包在另一个镜像和容器中的卷）。

    • 2

相关问题