From a88e760c9fcab473d0397e3e43bf2802323f5710 Mon Sep 17 00:00:00 2001 From: SamMa Date: Thu, 23 Jun 2022 12:14:18 +0800 Subject: [PATCH] Update 20210104 Docker Compose- a nice way to set up a dev environment.md --- ...pose- a nice way to set up a dev environment.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/translated/tech/20210104 Docker Compose- a nice way to set up a dev environment.md b/translated/tech/20210104 Docker Compose- a nice way to set up a dev environment.md index 99b18735b6..e0e52fe529 100644 --- a/translated/tech/20210104 Docker Compose- a nice way to set up a dev environment.md +++ b/translated/tech/20210104 Docker Compose- a nice way to set up a dev environment.md @@ -75,7 +75,7 @@ services: ### 网络互通也非常简单 -有件很重要的事：容器之间得能够互相连接才行。Docker Compose 让这件事变得超级简单！假设我有一个 Rails 服务正在名为 `rails_server` 的容器中运行，端口是 3000，那么我就可以通过 `http://rails_server:3000` 来访问该服务。就是这么简单！ +容器之间的互通也是一件很重要的事情。Docker Compose 让这件事变得超级简单！假设我有一个 Rails 服务正在名为 `rails_server` 的容器中运行，端口是 3000，那么我就可以通过 `http://rails_server:3000` 来访问该服务。就是这么简单！ 以下代码片段截取自我的 Nginx 配置文件，它是根据我的使用需求配置的（我删除了许多 `proxy_set_headers` 行，让它看起来更清楚）： @@ -88,7 +88,7 @@ location @app { } ``` -或者，你也看下面这个代码片段，它截取自我的 Rails 项目的数据库配置，我在其中使用了数据库容器的名称（`db`）： +或者，你可以参考如下代码片段，它截取自我的 Rails 项目的数据库配置，我在其中使用了数据库容器的名称（`db`）： ``` development: @@ -188,22 +188,22 @@ irb(main):001:0> 我碰到了一个问题：Rails 控制台的历史记录丢失了，因为我一直在不断地重启它。 -不过，我也找到了一个相当简单的解决方案（嘿嘿）：我往容器中添加了一个 `/root/.irbrc` 文件，它能够把 IRB 历史记录文件的保存位置指向到一个不受容器重启影响的地方。只需要一行代码就够啦： +不过，我也找到了一个相当简单的解决方案（嘿嘿）：我往容器中添加了一个 `/root/.irbrc` 文件，它能够把 IRB 历史记录文件的保存位置指向一个不受容器重启影响的地方。只需要一行代码就够啦： ``` IRB.conf[:HISTORY_FILE] = "/app/tmp/irb_history" ``` -### 我还是不知道它在生产环境的表现会怎么样 +### 我还是不知道它在生产环境的表现如何 到目前为止，这个项目的生产环境搭建进度，还停留在“我制作了一个 digitalocean droplet（LCCT 译注：一种 Linux 虚拟机服务），并手工编辑了很多文件”的阶段。 -嗯……我相信我以后会在生产环境中使用 docker-compose 来运行一下它的。我猜它能够会正常工作，因为这个服务很可能最多只有两个用户在使用，并且，如果我愿意，我可以容忍它在部署过程中有 60 秒的不可用时间。不过话又说回来，出错的往往是我想不到的地方。 +嗯……我相信以后会在生产环境中使用 docker-compose 来运行一下它的。我猜它能够正常工作，因为这个服务很可能最多只有两个用户在使用，并且，如果我愿意，我可以容忍它在部署过程中有 60 秒的不可用时间。不过话又说回来，出错的往往是我想不到的地方。 推特网友提供了一些在生产中使用 docker-compose 的注意事项： * `docker-compose up` 只会重启那些需要重启的容器，这会让重启速度更快。 - * 有一个 Bash 小脚本 [wait-for-it][3]，你可以用它来让一个容器保持等待，直到另一个容器的服务可用。 + * 有一个 Bash 小脚本 [wait-for-it][3]，你可以用它来保持等待一个容器，直到另一个容器的服务可用。 * 你可以准备两份 `docker-compose.yaml` 文件：用于开发环境的 `docker-compose.yaml` 和 用于生产环境的 `docker-compose-prod.yaml`。我想我会在分别为 Nginx 指定不同的端口：开发时使用 `8999`，生产中使用 `80`。 * 人们似乎一致认为，如果你的项目是一台计算机上运行的小网站，那么 docker-compose 在生产中不会有问题。 * 有个人建议说，如果愿意在生产环境搭建复杂那么一丢丢，Docker Swarm 就或许会是更好的选择，不过我还没试过（当然，如果要这么说的话，干嘛不用 Kubernetes 呢？Docker Compose 的意义就是它超级简单，而 Kubernetes 肯定不简单 :)）。 @@ -212,7 +212,7 @@ Docker 似乎还有一个特性，它能够 [把你用 docker-compose 搭建的 ### docker-compose 会有不适用的场景吗 -我听说 docker-compose 在以下场景的表现差强人意： +我听说 docker-compose 在以下场景的表现较差： * 当你有很多微服务的时候（还是自己搭建比较好） * 当你尝试从一个很大的数据库中导入数据时（就像把几百 G 的数据存到每个人的笔记本电脑里一样）