Docker本身就是一件很酷的年轻事物。 然后以某种方式使码头工人不再变得有趣：他就是，他在每个人中和所有事物中。 它具有所有微服务，Kubernetes，devops-任何东西。 但是，人们将容器从任何地方拖到他们的嘴里。 他们甚至常常不知道里面有什么。
DevOps工程师现在感兴趣的是什么？ 超级英雄团队-DevOops会议的程序委员会-在环聊中陷入了恶魔般的陷阱，并回答了一个小时的问题。 （这些人都是谁-
在此处详细说明）。
剪下-面试，用蜡笔上色。 每个专家都有自己的颜色：
巴鲁克，您认为自从上次DevOops以来，世界发生了什么？ 
在我看来，最明显的是，最有趣的是Kubernetes在所有领域的起飞，而在非显而易见的领域-不太明显但同样重要的docker消费化。 
也就是说，在Docker并非适合所有人之前？
不行 Docker本身就是一件很酷的年轻事物。 然后以某种方式使Docker不再变得有趣，那就是它在那里，每个人都拥有它，它拥有所有微服务，Kubernetes，devops，一切，任何东西。 但是，泊坞窗本身作为一种技术突然间不再对任何人感兴趣。 不要在服务器上运行相同的Java，显然是容器。 这真的让我着迷。
人们通常会讨论他们遇到的问题或直接任务。 码头工人没有问题，他们在那里吗？
泊坞窗中有很多问题，这些问题确实得到了解决。 此外，我们不再使用docker那些痛苦的部分。 码头工人有他可以做得很好的事情。 还有一些不好的。
举个例子。
例如，Unix进程中的监狱-那里的一切都非常好，很聪明。 它真的很酷。 但是，例如，在容器，群集，部署中运行的微服务之间的连接性，简直是一场噩梦。
您是说他们试图跟上Kubernetes的蜂群吗？ 
是的，我的意思是Compose，那简直就是一场噩梦和地狱。 我们决定不使用它，而只使用可以理解且免费的有效方法。 一方面，泊坞窗变得非常酷，另一方面，不再有趣。 码头工人和码头工人-很好。
现在，当您查看一个新软件时，首先要查看是否有现成的容器。 最好由该软件的制造商提供。 然后，您将看到如何展开它并用魔杖戳它。 Docker为我们提供了可在工作机器上戳戳的复杂服务。 现在，无论您是罂粟还是Linux，都不再那么重要。 相同的Sentry包含5-6个组件，您将分别开始使用它们。 而且，如果您仅要做一项任务，看看这种物品的外观，请发送信号并观察其在此处的分解情况。 现在将需要15分钟-它已经启动，已部署，并且该部分将使用Ruby，Java中的部分，上帝禁止，一些Elasticsearch-将与同一个Docker一起死亡。
最重要的是，他将在以后死亡。 
是的，这是一个单独的魅力。 以前，您可以欺骗自己进入系统，以便在/ usr / local中没有任何内容。 而且仍然上升-在/ opt中的某个人，在/ usr / local中的某个人，某个地方的其他人。 并且您的系统膨胀，所有不必要的东西都变得多余。 这是一个，第二个-您越没有必要，对您的攻击向量就越大，因此您可能会因此而受到冒犯。 而且由于我们现在正在docker中启动所有这些操作，因此这里的安全性和整洁度不会给我们带来任何讨厌的事情。
听着，女士们，先生们，您正在组织关于devop的会议，如果docker变得无聊和无趣，那么现在将不会有docker？
首先，码头工人将无处不在。 仅仅是因为它变得无聊和无趣，并不意味着它将停止使用。 相反，这意味着我们现在正在使用它，并且没有引起注意。 也就是说，他无处不在。 这不是在会议上进行单独讨论的主题。
他有报告吗？ 如果我现在进入程序并写单词docker，会不会有什么？
写。 让我们做一个精彩的实验。
写着说： 确保容器部署安全的实际步骤
这反映了以下事实：泊坞窗允许我们的现代系统以自然的方式更加安全。 此外，它还反映了另一件事，最近也可能发生了变化……Devops变得越来越多。 可以说，大公司开始越来越多地渗透他们。 与他们一起，关于安全性的话题也开始了越来越多的讨论，安全性可以由开发人员提出，或者反过来破坏安全性。 利兹（Liz）的报告是关于如何妥善准备这场战斗以使您的警卫感到高兴的。 
您个人认识说话者吗？ 谁是丽兹·赖斯？
利兹是泥盆纪景观中的重要人物。 她是所有KubeCon的负责人。 实际上，首先，利兹（Liz）是一位非常出色的发言人。 其次，她在负责集装箱安全的Aqua Security公司工作。 在集装箱安全方面，我们找不到比专门从事此工作的人更好的人了。 我看到了许多Liz的报告，特别有趣的是，她正试图解决一个相当复杂的问题。 问题在于，今天，安全首先是复杂的，并且随着攻击变得越来越复杂，安全性也越来越复杂。 因此，防御它们变得更加困难，我们必须在REST上加密我们的信息，我们必须在流量中加密各种TLS，https，证书，协议……这一切都很复杂 。 以字母A结尾。 首先，这很困难，其次，它并没有摆脱它，因为您现在不能说：“哦，我不知道，我们不要做https。 好吧，谁在乎我需要谁。” 由于同一个恶毒的Chrome浏览器会立即对您的所有用户大吼大叫，因此您无法确保一切安全。 这种复杂性和必要性的结合冻结了，因为这不是我们的关注，我们也不是所有人都安全。 另一方面，这取决于我们，因为我们不能简单地忽略这些方面。 Liz在她的报告中试图将容器安全的关键方面简单而清晰地传达给远离安全的人们，这很酷。
还有另一个问题，人们从任何地方都将容器拖到他们的嘴里。 他们甚至常常不知道里面有什么。 如果您想将魔杖粘在笔记本电脑上是一回事。 另一件事是将其拖入生产。 而且，不幸的是，许多人拖累了任何打击。 就是说，您需要一些难以组装的东西，如果是制造商的话，他们会妥善保管成品并保管好常规的基础容器。 这是相同的攻击媒介。 例如，在不久的将来，我们可以掀起一波同名的容器浪潮，就像pip模块和get模块一样。 与域一样，一切都一样。 也就是说，这不是一个新问题，它仍然是旧的。 当一种服务成为商品时，当它如此分发时，人们就会来到那里惩罚那些不监视安全性的人。 顺便说一下，因此，我们有很多关于安全性的报告。
还有什么？
我们仍然需要处理塞思·瓦尔戈（Seth Vargo）的秘密。 顺便说一句，将与他举行一次安全圆桌会议。
塞思（Seth）是Google曾经在HashiCorp工作的人吗？
在此之前，他曾在Chef Software工作，并在Chef达到顶峰时成为那里的明星。 他几乎在每本食谱中都留下了印记。 有些人甚至不喜欢他参加这项活动。 然后，他在HashiCorp继承了很多遗产。 而这条HashiCorp火车仍在追随他。 在这里，他将谈论HashiCorp产品。 他不会谈论Google。 但是在标题中他将拥有Google，因此增加了分量。
顺便问一下，厨师怎么了？
在某些地方，厨师被这些集装箱杀死了。
据我所知，编写和工作的Chef应用程序可以继续工作很长时间，因为配置管理本身并未消失。
伙计们，我可以举一个生动的例子告诉你。 我们有一些不在Docker中的东西，然后在Chef之下。 因为服务器雪花没有走到任何地方。
您刚刚对厨师说了些什么。 不在docker下的是在Chef之下。 但是在Docker下，我们几乎拥有一切。
一切都是正确的，但是仍然存在使用寿命长的服务器，这些服务器的数据没人希望推送。 在这里，他们仍将与Chef一起生活一段时间，因为生活在正常世界中的每个人都不想回到手动控制领域。
顺便说一句，有人在使用Ansible吗？
是的，Ansible也在那里。
我们正在使用。
又如何？ 为什么Ansible？
惊人的以惊人的速度变成垃圾的能力。 这是Ansible留下的印象。 我一生中从未遇到过如此地狱般的融合。
似乎我们有关于此的报告！
没错 它不仅有助于将与Ansible合作的结果变成我提到的内容。 真是太神奇了，对不起，当我们写这本书的时候，我没有看到他。
您说一切都在docker下启动，但是服务器本身需要以某种方式配置才能在其上运行管理程序吗？
不，您带它去亚马逊...
啊，骗子，在亚马逊。 知道了
或Terraform-随处可见。
最先进的。 关于这一点，我们也有一份报告 。
Terraform满足了这一需求，因为有一堆提供程序，它们的虚拟机以不同的方式启动，并且当您的计算机出现时，您可以使用Terraform关闭该层。 然后，您将在Terraform中拥有一些预配器，同一主厨和同一Ansible。 一些供应商倒入下一层，然后Docker飞往这台现成的最小机器。 获利
这份报告是由为Terraform做aws模块的人领导的？
他为Amazon模块做了很多工作，但这是社区的一部分。 这个人也很有趣，如下所示：自从他与Terraform一起生活了很长时间以来，这些年来，他一直在社区中形成一些最佳实践，而这些最佳实践在Terraform周围还远远不够，因为在某些地方如此简单等等不允许您进行不必要的动作，有时说明过于复杂。 您将拥有一个非常复杂的相互连接的结构，或者反之亦然。 我们希望只是谈论所有这些问题的安东·巴本科（Anton Babenko）将帮助您理清如何与Terraform一起生活，而不要遭受痛苦。 如何开发满足个人需求的模块，以使它们继续保持简洁，可读性，并且顺便说一句，那里也没有人进行任何测试。
没有人尝试过从更方便的元语言中生成这些Terraform鞋类吗？
有这样的想法。 我们尽量不要这样做。 实际上，Terraform那里的数据结构仍然可以不生成，但是很困难。 想象一下，您在亚马逊中的不同地区有多个vpc，需要在它们之间建立对等关系，然后就可以开始冒险了。 在API的每个区域中，入口点都是不同的，而Terraform是您所谈论的一个。 也就是说，您需要在描述中解析这些入口点，描述每个vpc，并在不同区域中对等这些vpc之间的连接。 所有这些都必须以某种方式进行描述。 我们的人使用他们的模块来完成它，并且至少通过某种方式，它才得以生存。 一般来说，很难，很难。 但是，如果Terraform提供了更多的可能性，那么……当变量内部的变量被预热时，这叫什么？
Kotlin DSL。 
<所有人都开怀大笑>
可变变量或插值-取决于您的意思。
通常，这不是一种成熟的语言，它被截断了。 与Kotlin DSL不同，他使您编写起来尽可能简单，而Kotlin DSL却使您掌握了成熟的Kotlin。
那么，如何解决您自己理解的Kotlin DSL的所有限制？
什么啊
Groovy DSL自然解决了！
这里有许多使用过TeamCity的人吗？
当然可以 槽DSL，科特林DSL，我们有一份报告！
当然可以吗？
不是我这样做，不！ 我们将只有带有Kotlin DSL的TeamCity以及与詹金斯的Groovy DSL的比较。
来自JetBrains的人到达了吗？
不行 这是一个单独的魅力。
我们有真实的用户，没有营销。
每个人，我都放弃了，还有谁可以报告TeamCity？
使用一家在俄罗斯广为人知的Tinkoff小型公司。 在这里，他在程序中 。
是的，说一点，与所有讨厌但普遍使用的詹金斯和他的Groovy DSL进行比较。
我们必须走下去，倾听并找出巴鲁奇的魅力在选择技术方面发挥了什么作用。
没有 我完全从这一切中抽象出来。 没有muhlezh，一切都会诚实。
我的意思是Tinkoff之所以采用所有这些时髦技术是有原因的，TeamCity不是20年前的某种企业，就像银行通常那样。
Tinkoff是一家从一开始就这样做的银行。 赶时髦的人的银行。 因此，那里的技术是新鲜且正确的。
伙计们，我真的每天都在使用TeamCity，在最新版本中，它变得很棒。 TeamCity DSL现在可用。 查看最新版本的问题所在。 在以前的版本中，如果切换到Kotlin DSL，则无法继续使用该接口。 一旦越界，进一步书写的唯一方法就是在Kotlin上。
就这样，您踩到了黑暗面。
是的，文档最少，而且很简单。 因此，我们尝试将其回滚到XML配置。 在最新版本中，当您切换到Kotlin DSL时，您将继续使用Web界面，它在后台形成补丁，直接在存储库中对这些结构进行补丁。 然后，如果您已经掌握了某些内容，则可以放心地继续用Kotlin编写。 那些尚未献身的人可以继续在界面中四处寻找。 这太好了！
这是安东·阿基波夫的有益影响。
顺便说一下，这里提到了各种实践。 我们是否有专门针对某些流程，文化和人的方面的报告？
自然地。 首先，我们有萨沙·蒂托夫（Sasha Titov）和基里尔·托尔卡切夫（Kirill Tolkachev）的精彩闭幕演讲，他们将讨论发展中一切是否糟糕还是仍然存在希望。 
对我而言，似乎很重要的一点是，DevOops可能是目前几乎由JUG.ru集团组织的唯一一次专业会议，在该会议上可以正式和正式地谈论社交和流程问题。
为此，我们必须与JUG.ru集团的管理层进行密切交谈，但最终结果是亲自面对。
除了这个漂亮的主题演讲之外，我们还提供了Dell EMC的报告，该报告也与流程有很大关系。 这是关于公司内部的一个团队，该团队编写供内部使用的服务。 编写此服务是一回事，而开始使用它则是另一回事，因为所有人都很忙，他们没有时间掌握行家技术。 因此，编写服务，然后在公司内部出售。 用户会来找您，各种各样的非标准需求将开始出现，这给您带来了难题–开发一项服务，以便许多人可以使用它或满足这个特定的团队。 我们也希望在那里。
将会有一个可怕的两年故事的描述，该故事不再像开始时那样病态。
巴鲁克，您是否也在讲一些高度社交化的内容？
Lenya Igolnik和我有一个有关如何立即开始进行测量的报告，这就是我们开发人员中出现的所有耻辱。 自然地，我们有一些度量标准，我们可以从开发人员那里获得这些度量标准，这些度量标准我们不会使用，也永远不会使用。 我们拥有运维带来的指标，而这些指标总是好得多。 问题是，devops指标到底是什么？ 这是什么意思？ 是仅仅采用这些并采用其他方法，还是一些新的，新的指标？ 简而言之， 数据驱动的开发者 。
巴鲁克（Baruch），有时是读者，访问者对程序委员会的同志们正在阅读他们的报告感到愤慨，他们认为这是不诚实的。
我们真的考虑到了所有这些。 至少，我们正在努力吸引尽可能多的发言人，他们不仅来自计划委员会。 但是同时，我们仍然希望看到一些PC参与者作为发言人。 例如，Rancher Labs的首席工程师Alena Prokhorchik可能在多云Kubernetes部署方面拥有世界上最丰富的经验。 我想每个人都想听听，她有话要说 。 作为程序委员会，我们在评估报告方面享有专业知识。 当整个会议由程序委员会的发言人组成，并且每个人都有五份报告时，这确实不好。 但是，如果我们有一位出色的演讲者想要帮助计划委员会，老实说，我不明白为什么我们应该选择其中一个。
巴鲁克（Baruch），您工作，加之经常出差，并在计划委员会工作。 你有生命吗？ 您如何做所有事情？
参加JUG.ru集团会议的志愿服务非常愉快，因为它带来了很多乐趣-此外，我正在学习一种新的知识。 运行比我了解得多的人的报告非常有用。
知道了 是否有人想在与Baruch的独白中添加一些内容？
我经常说我听到过没有人听到的报道。
是的，程序委员会不仅听到会议的内容。 比赛是三分之一。 我们可以说发生了这种情况，因为在应用程序中有许多非常有趣的应用程序。 我们过滤掉的部分内容是在其他会议上推荐的。
您是否需要按数量过滤任何主题？ 例如，Kubernetes。 还有什么吗
监控方式 我们为监视而战。
一堆报告。 每个人都喜欢监视。
谁赢得了这座山丘之王？
Alexey Kirpichnikov，报告“我们在建立自己的紧急通知系统时学到了什么” 。
我想在程序中有什么东西但没有专家吗？
你脱掉舌头。 硬币有一个反面，我们钟爱的无服务器，似乎正在大肆宣传，但是没有一个人认为很好并且在实践中应用了所有这一切。 我希望我们至少有一个。 但总的来说，公司几乎没有行业经验。 巴鲁克，福音专家呢？ 他们也不在那里吗？ 还是没有人来找我们？
整个签证的过程确实在很多方面破坏了我们的处境，包括与开发者倡导者一道，他们想来谈论无服务器，特别是来自Amazon的lambda。 不幸的是，获得签证后，一切都停滞了。
并且有些报告中您确实为自己学到了一些以前从未有过的新东西？ 还是您还记得一些突破性的东西？
作为程序委员会中最非技术人员之一，我不断地发现一堆新东西，这些东西我以后带给我的工程师，他们说，是你带给我的101。 但并非总是如此！
, , , ?
, , . , . - . , Ansible , . Ansible, . , , - . : , , , , . , , , .
, , . , , . .
.
?
. . , , , .
stateful , -, .
, . managed PostgreSQL … , - , — . , , , .
, - , . , ?
. Kubernetes , , . , , - , .
, . - , ? - , - , ?
— . , , , . , ( — , ) — , . JUG.ru Group , , . , , . . , (BOF). , , SRE. security, — , , , , . , , , -, , — , , :-)
- ?
, .
« , , » — , .
?
, , , . .
, , , - Java Virtual Machine, BOF . , , , - .
JVM, , , . , , , .
, — , , . , .
, . DevOops , . . , people + processes, , , .
, , TechTrain, .
, . , , , , . , TechTrain, . , TechTrain . JUG.ru Group, — . , . , . , , , .
, , — « » ( ).
, . -, , , . — , .
DevOops !
, , Joker , Java . , , — .
, , , DevOops - . , every company is a software company, - .
谢谢大家的采访！在准备文章时，我们将与您会面很多次，但是与Habr的读者一起，我们只会在DevOops见面。祝您一切顺利，很快再见！
DevOops会议将于2018年10月14日在圣彼得堡举行。如果您突然喜欢我们在这里讨论的程序，那么一定要来。门票在这里。