在赢得DevOps的时代，开发人员仅需了解Docker容器，为什么需要它们以及如何使用它们。 这极大地方便了工作。 此外，即使是在Visual Studio 2017开发环境中使用.Net Core的人员也可以感受到容器化的全部功能。在
Panda-Meetup C＃.Net会议上，服务器应用程序开发部门负责人Pavel Skiba谈到了可用的工具以及为VS配置Docker。
开发人员应该做什么？ “程序，”您回答，然后……猜。 但是，如果早先必要知识的清单就此结束了，那么在DevOps时代，它才刚刚开始。 在编写代码时，我们绝对需要了解网络结构：什么与什么相互作用。 同时需要多种编程语言的支持，并且项目中的不同代码段可以用任何东西编写。
如果检测到错误，我们需要知道如何回滚软件。 我们需要管理公司中使用的不同环境的配置-这些至少是几个开发环境，测试和战斗环境。 哦，是的，您仍然需要了解不同服务器/操作系统上的脚本，因为不是所有事情都可以使用代码来完成，有时您必须编写脚本。
我们需要知道安全性要求，它们变得越来越严格，并占用了开发人员很多时间。 不要忘了相关软件的支持和开发：Git，Jenkins等。 结果，开发人员可能根本没有足够的时间进行纯开发。
怎么办 有一个出路，它位于Docker容器及其管理系统中。 一旦部署了所有这些复杂的庞然大物，就像过去那样，您将只再次编写代码。 其他所有内容都将由其他人或系统本身控制。
我们了解容器
什么是Docker容器？ 这是一个由几层组成的结构。 顶层是应用程序的二进制层。 现在，第二层和第三层已集成到.Net Core中，该容器已经是SDK-shny。 下一层取决于容器在其上部署的操作系统。 最底层是操作系统本身。
在较低级别，部署了Windows Nanoserver。 这是Windows Server的巨大缺陷，只能维护已部署的实用程序。 但是她的音量却少了12倍。
如果我们比较物理服务器和虚拟服务器以及容器，那么后者的好处显而易见。
当一切都在物理服务器上运行时，我们面临许多问题。 库代码中没有隔离；某些应用程序可能会相互干扰。 例如：一个应用程序在.Net 1.1上工作，另一个在.Net 2.0上工作。 大多数情况下，这导致了悲剧。 一段时间后，出现了虚拟服务器，隔离问题得以解决，没有共享库。 没错，与此同时，这在资源和劳动力方面变得非常昂贵：有必要始终监视一个虚拟机，Hyper-V和一块铁板上有多少个虚拟机在旋转。
容器被设计为一种廉价且方便的解决方案，与操作系统的相关性最小。 让我们看看它们有何不同。 系统内部的虚拟服务器大致位于此位置。
底层是主机服务器。 它可以是物理的也可以是虚拟的。 下一层是任何具有虚拟化功能的OS，上方是虚拟机监控程序。 顶部是虚拟服务器，可以将其分为来宾操作系统和应用程序。 也就是说，在每个虚拟服务器下，来宾OS都部署在OS之上，这会浪费资源。
让我们看看Linux容器如何在系统上定位。
如您所见，具有应用程序的二进制文件直接位于主机服务器和OS上方。 不需要来宾操作系统，可以释放资源，不需要来宾操作系统的许可证。
Windows容器与Linux略有不同。
基本层是相同的：基础结构，主机OS（但现在是Windows）。 但是，这些容器可以直接与操作系统一起使用，也可以部署在虚拟机管理程序之上。 在第一种情况下，进程和空间是隔离的，但是它们与其他容器使用相同的核心，从安全的角度来看，这不是冰。 如果通过Hyper-V使用容器，则所有内容都将被隔离。
学习Docker for VS
让我们继续研究Docker本身。 假设您拥有Visual Studio，并且是第一次安装Windows的Docker客户端。 在这种情况下，Docker将部署Docker恶魔服务器，Rest上用于访问它的接口以及客户端本身-Docker命令行。 这将使我们能够管理与容器相关的所有内容：网络，图像，容器，层。
幻灯片显示了最简单的命令：拉出Docker容器，启动它，收集，提交，发送回去。
Docker与Visual Studio有机结合在一起。 屏幕快照显示了Visual Studio 2017中的面板菜单。Docker compose支持直接集成到Intellisense中，支持Dockerfile，所有工件均在命令行上运行。
有趣的是，我们可以直接对Docker进行实时调试。 而且，如果您的容器彼此连接，那么它们将立即立即被删除，而您将不需要运行多个环境。
容器如何组装？ 此处的主要元素是dockerfile，其中包含用于构建映像的说明。 为每个项目创建每个dockerfile。 它指示：我们从哪里获得基本映像，我们传递什么参数，带有文件，端口的工作目录的名称是什么。
此源参数有两个参数。 第二个参数是将装配结果放置在项目中的路径，该值默认设置。 我认为这不是一个很好的选择。 此文件夹通常有很多垃圾，需要定期清理，当我们清理此文件夹时，可以擦拭装配体。 因此，您可以根据需要更改它，它是由Docker_build_source系统参数设置的，也可以对其进行锤打。
Entrypoint指令允许您将容器配置为可执行文件。 .Net Core需要此行，以便在容器成功启动后，它会向命令行发送消息“您的应用程序正在运行”。
现在介绍调试容器。 这里的一切都像一个普通的.Net，您几乎不会注意到它们之间的区别。 最常见的是，我在dotnet.exe下以自托管的身份运行.Net Core。 它使用CLRDBG调试器，NuGet数据包缓存和源代码。
ASP.Net 4.5+由IIS或IIS Express托管，使用Microsoft Visual Studio调试器和IIS中站点根目录的源。
有两种调试环境：调试和发布。 调试映像标记被标记为dev和最新版本。 调试时，最好将Source参数设置为obj / Docker / empty，以免混淆，但是在发布obj / Docker / publish时。 在这里，您可以使用所有相同的二进制文件，视图，wwwroot文件夹以及所有存在的依赖项。
掌握Docker Compose
让我们继续学习有趣的部分：Docker-compose Orchestration工具。 让我们看一个例子：您有某种业务服务会影响5-6个容器。 而且，您需要以某种方式确定应如何组装它们。 这是Docker-compose派上用场的地方，它将提供容器的所有组装，启动和缩放。 它管理简单，一切都由一个团队收集。
Docker-compose使用YAML文件来存储容器组装方式的配置。 它们描述了您需要为映像本身，部件，服务，卷，网络，环境使用哪些设置。 对于在群集中发布，语法相同。 也就是说，一旦他们编写了这样的文件，并且如果将来有必要在集群中部署业务服务，则无需添加任何其他内容。
考虑YAML文件的结构。 映像是Docker映像。 图像是没有应用程序层的容器；它是不可变的。
构建指示如何构建，在哪里构建以及在哪里部署。
Depends_on-依赖于它所依赖的服务。
环境-在这里我们设置环境。
端口-端口映射，您的容器将在该端口上可用。
考虑一个例子。 我们只有一个没有服务的API，实际上是3个容器：Linux上有SQL.data，应用程序本身，它取决于webapi，而webapi取决于SQL.data。
组件以什么顺序写入文件中无关紧要。 如果正确描述了所有内容，则Compose将根据项目中的依赖关系自动正确构建此信息。 该文件足以一次收集所有容器，输出将是完成的版本。
有一种“容器容器”，一个特殊的容器docker-compose.ci.build.yml，其中组装了整个容器。 您可以从Visual Studio命令行运行此特殊容器，它将能够在构建服务器上完成组装，例如在Jenkins中。
看一下文件内部。 该示例包含工作目录及其来自何处。 他从GIT还原项目，亲自发布此解决方案，配置发布并上传结果。 这就是整个团队的建设，不需要编写其他任何东西。 只需注册一次，然后用一个按钮启动发布就足够了。
还有什么值得关注的。 Docker-compose为每个环境收集图像，为每个配置提供一个单独的文件。 对于Visual Studio中的每个配置，都有一个文件，其中包含环境所需的设置。
直接从VS，您可以远程开始调试整个合成。
集群协调器
最后，我们涉及集群编排器等主题。 我们不应该考虑容器如何继续存在，管理哪些人员或系统。 有四种最受欢迎的容器管理系统：Google Kubernetes，Mesos DC / OS，Docker Swarm和Azure Service Fabric。 它们使您可以管理容器的群集和组成。
这些系统能够处理大量的微服务，为它们提供一切必要的东西。 开发人员只需配置一次该层。
完整的熊猫聚会聚会表演可在下面找到。
对于那些想深入研究该主题的人，我建议您学习以下材料：
http://dot.net
http://docs.docker.com
http://hub.docker.com/microsoft
http://docs.microsoft.com
http://visualstudio.com
最后，来自实践的重要建议是：最困难的事情是记住所在位置。
使用Docker容器时的文档将落在您的肩膀上。 没有文档，您将忘记在哪个容器中什么与什么以及什么有效。 服务越多，连接的网络越多。