当开始使用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套接字了。