mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
Update 20210104 Docker Compose- a nice way to set up a dev environment.md
This commit is contained in:
parent
64f1bf91c9
commit
a88e760c9f
@ -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 的数据存到每个人的笔记本电脑里一样)
|
||||
|
Loading…
Reference in New Issue
Block a user