本文由 简悦SimpRead 转码，原文地址 jugmac00.github.io
直到最近，我都没有看到使用Docker的好理由，因为我选择的部署工具产生了approxim......。
直到最近，我认为没有很好的理由使用Docker，因为我选择的部署工具在我的Ubuntu笔记本上、在staging和production上产生的构建都是大致相同的。
但时间不会停滞不前，尤其是当我要部署一个Java应用程序时，是时候重新考虑我的策略了，因为我不想玩哪个Java运行时环境与哪个应用程序版本配合得好的游戏。
幸运的是，JetBrains为YouTrack提供了预构建的docker镜像，这是我最喜欢的问题跟踪器，也是我今天打算安装的应用。
简单并不总是更好
有了预置的Docker镜像，运行应用程序就可以简单到......
docker run -it --name youtrack-server-instance \
-v {path to data directory}:/opt/youtrack/data \
-v {path to conf directory}:/opt/youtrack/conf \
-v {path to logs directory}:/opt/youtrack/logs \
-v {path to backups directory}:/opt/youtrack/backups \
-p {port on host}:8080 \
jetbrains/youtrack:{version}
......但是输入这么长的命令是很乏味的，而且这个过程在主机系统重启后也会失效。
注意
你知道
docker create、docker run和docker start之间的区别吗？
既然我们在这里，让我们来剖析一下这个复杂的命令。
run创建并启动一个容器-it提供一个交互式的tty，即在终端显示输出--name给容器一个名字-v在主机和容器之间映射文件夹-p在主机和容器之间映射端口jetbrains/youtrack:{version}是最后的docker镜像。
以systemd服务的形式运行docker容器
与其手动启动docker服务，不如使用systemd来启动它，即使在重启后也是如此。
JetBrains提供了一个简明文档，介绍如何做到这一点。
单元文件
基本上，只要在/etc/systemd/system/docker.youtrack.service创建一个单元文件，内容如下
[Unit]
Description=YouTrack Service
After=docker.service
Requires=docker.service
[Service]
TimeoutStartSec=0
Restart=always
ExecStartPre=-/usr/bin/docker exec %n stop
ExecStartPre=-/usr/bin/docker rm %n
ExecStartPre=/usr/bin/docker pull jetbrains/youtrack:<version>
ExecStart=/usr/bin/docker run --rm --name %n \
-v <path to data directory>:/opt/youtrack/data \
-v <path to conf directory>:/opt/youtrack/conf \
-v <path to logs directory>:/opt/youtrack/logs \
-v <path to backups directory>:/opt/youtrack/backups \
-p <port on host>:8080 \
jetbrains/youtrack:<version>
[Install]
WantedBy=default.target
......其中，在一个非常高的水平上。
- 单元部分给这个服务一个名字，并定义了前提条件和依赖性。
- 服务部分配置了要执行的命令。
- 而安装部分定义了这个服务应该何时启动。
最后，你可以通过systemctl enable docker.youtrack来启用它，这样它就会在下次重启后启动，并通过sudo service docker.youtrack start/sudo service docker.youtrack stop手动启动和停止。
一些故障
这一切都运行得很好，YouTrack可以通过我的浏览器使用，只是我对systemctl status docker.youtrack的输出有点担心......
为什么会有两个失败？
根据我对Docker的了解，运行命令应该是创建并启动一个容器，所以这个容器应该是持久的，即使在重启后也是如此。
这最终意味着，systemd应该成功地停止和删除docker容器，例如，在重启时。
剖析单元文件中的服务部分
让我们再来看看上面的 Service 部分，特别是下面两行。
ExecStartPre=-/usr/bin/docker exec %n stop
ExecStartPre=-/usr/bin/docker rm %n
ExecStartPre是很好的自我解释，意思是 "在启动服务前执行这个命令"- 命令前的破折号，
-，意味着当下面的命令失败时，它是可以的 = 不要在失败时停止! %n扩展到服务，即docker.youtrack.service。
所以，这意味着，失败是可以预期的!
让我们来看看run命令...
ExecStart=/usr/bin/docker run --rm --name %n。
ExecStart是主进程docker run，正如我们现在所知道的，创建并启动一个容器--rm--在这里，这将确保容器在退出时被删除!--name设置容器的名称%n是服务的占位符
结论
一切都像预期的那样工作!
stop和delete命令只是安全防护措施，以防存在另一个同名的容器，或者甚至正在运行。
运行预先构建的Docker镜像是一件很容易的事。
但你肯定应该知道这些基本知识 :-)
