在引入secrets之前，向容器传递信息的一种常用方法是通过环境变量。对于非机密信息，这仍然是首选的方式，但设置的一部分也应该会涉及secrets。两者应该结合起来。问题是在什么时候选择哪种方法。
Docker secrets最明显的用例就是机密信息。很明显，不是吗？如果有一条信息除了特定的容器外，任何人都不能看到，那么它就应该通过Docker secrets来提供。常用的模式是允许将相同的信息指定为环境变量或secret。如果两个都设置，那么secrets应该优先。你已经通过Docker Flow Proxy看到了这种模式。可以通过环境变量指定每一条信息，也可以指定为secret。
某些情况下，你可能无法修改服务的代码并将其修改为使用secrets。也许这并不是能力问题，而是缺乏修改代码的意愿。如果你属于后一种情况，那么现在我会忍住不去解释为什么应该不断重构代码，并假设你也有一个很好的理由不去修改代码。在这两种情况下，解决方案通常是创建一个wrapper脚本，将secrets转换为服务所需的任何内容，然后调用该服务。将该脚本作为CMD指令放在Dockerfile中，你就完成了。secrets是保密的，你不会因为重构代码而被解雇。在某些人看来，最后一句听起来很傻，但对于公司来说，认为重构是浪费时间的事并不少见。
什么应该是secret呢？没有人能真正地为你回答这个问题，因为它因组织而异。其中一些例子是用户名和密码、SSH密钥、SSL证书等。如果你不想让别人知道这件事，那就把它当成secret。(www.xing528.com)
我们应该努力争取不变性，并尽量运行容器，无论在哪运行，它们都是完全相同的。真正的不变性意味着在所有环境中的配置都是相同的。然而，这并不是容易的，有时甚至是不可能做到的。这种情况可能正是Docker secrets发挥作用的时候。它们不一定只被用作指定机密信息的手段。我们可以使用secrets作为不同集群提供不同信息的一种方式。在这种情况下，随环境不同而不同的配置（例如开发和生产集群）可以作为secrets存储。
我们确信还有很多其他的用例都没有想过。毕竟，secrets是一个新特性（编写本章的时候仅发布了几天）。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
