为什么不需要在 Docker 容器中运行 SSHD

当开始使用Docker时,人们经常问:“我该如何进入容器?”,其他人会说“在你的容器里运行一个SSH服务器”。但是,从这篇博文中你将会了解到你根本不需要运行SSHd守护进程来进入你的容器。当然,除非你的容器就是一个SSH服务器。

运行SSH服务器是很想当然的,因为它提供了进入容器的简便方式。在我们公司基本上每个人都最少使用过一次SSH。我们中有很大一部分人每天都会使用它,并且他们很熟悉公钥与私钥,无密码登录,密钥代理,甚至有时会使用端口转发和其他不常用的功能。正因如此,人们建议你在容器中运行SSH并不奇怪。但你应该仔细考虑下。

假设你正在假设一个Redis Server或Java Webservice的Docker镜像, 我会问你以下几个问题:

你需要用SSH来做什么? 一般来说, 你想做备份, 检查日志, 或者重启进程, 调整配置, 还有可能用gdb, strace或其他类似的工具来debug服务器。那我们会看一下我们怎么不使用SSH来做这些事情。

你怎么管理你的密钥和密码的?一般来说,你要么把它们写到你的镜像中,要么就把它们放在一个卷中。你想一下如果你要更新这些密钥或密码你会怎么做呢。如果你把它们写到镜像里了,你就需要重建镜像,重新部署它们,然后重启容器。这还好,不算是世界末日,但是这绝不是一个高大上的方法。把它们放到卷中,然后通过管理卷来管理它们倒是比前一种好得多。这种方法是可用的,可是却有严重的缺陷。你必须要确认容器没有这个卷的写权限;否则,容器有可能会破坏密钥(这让你之后就进不去容器了),如果你再用一个卷共享给多个容器的话,情况会变得更糟。如果不用SSH,我们不就少一个需要担心的事了吗?

你如何管理安全升级呢?SSH服务器是挺安全的,但是仍然会有安全问题,你会在必要的时候不得不升级所有使用SSH的容器。这意味着大量的重建和重启。也就是说,及时你有一个简单小巧的memcached服务,你还是不得不确保及时的安全更新,否则千里之堤可能毁于蚁穴。所以还是这句话,如果不用SSH,我们不就少一个需要担心的事了吗?

你需要“仅安装一个SSH服务器”来达到目的吗?当然不。你需要加装进程管理器,比如Monit或者Supervisor。这是因为Docker自己只会监视一个进程。如果你需要运行多个进程,你就必须在上面加装一层可以看着他们的应用。换句话说,你在把简单问题复杂化。如果你的应用停了(正常退出或者崩溃),你必须要从你的进程管理日志里面去查看,而不能简单的查看Docker提供的信息。

你可以负责把应用放到容器中,但你是否应该同时负责管理访问策略和安全限制呢?在小机构中,这都不是事。但是在大型机构中,如果你是负责设立应用容器的人,那很可能有另外一个人负责定义远程访问策略。你所在的公司很可能有严格的策略定义说明谁能访问,如何访问或者其他各种审查跟踪的要求。那样的话,你肯定不会被允许把一个SSH服务器扔进你的容器中。

但我该如何做… 备份我的数据?

你的数据应该存在于 volume中. 然后你可以使用--volumes-from选项来运行另一个容器,与第一个容器共享这个volume。这样做的好处:如果你需要安装新的工具(如s75pxd)来将你备份的数据长期保存,或将数据转移到其他永久存储时,你可以在这个特定的备份容器中进行,而不是在主服务容器中。这很简洁。

检查日志?

再次使用 volume! 如果你将所有日志写入一个特定的目录下,且这个目录是一个volume的话,那你可以启动另一个log inspection" 容器(使用--volumes-from,还记得么?)且在这里面做你需要做的事。如果你还需要特殊的工具(或只需要一个有意思的ack-grep),你可以在这个容器中安装它们,这样可以保持主容器的原始环境。

重启service?

基本上所有service都可以通过信号来重启。当你使用/etc/init.d/foo restart或service foo restart时,实际上它们都会给进程发送一个特定的信号。你可以使用docker kill -s <signal>来发送这个信号。一些service可能不会监听这些信号,但可以在一个特定的socket上接受命令。如果是一个TCP socket,只需要通过网络连接上就可以了。如果是一个UNIX套接字,你可以再次使用volume。将容器和service的控制套接字设置到一个特定的目录中,且这个目录是一个volume。然后启动一个新的容器来访问这个volume;这样就可以使用UNIX套接字了。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/d59d90a5cc6792c5414d50199433763d.html