参与者参加课程或强化课程。 他看到一排排有序的技术支持、整齐布线的电源线、棋盘式布局的报告厅、明亮的图片和幻灯片图表。 演讲者充满笑话和微笑，以一种让你有时间理解的方式传递信息。 看台已经搭好，练习任务就在你的指尖，只不过有时你需要技术人员的帮助。 支持。
还有与志趣相投的人一起喝咖啡休息，欢快而充满活力的氛围，交流经验，提出演讲者最意想不到的问题。 您在手册中找不到答案和信息，只能在实践中找到。
你认为需要多少时间、精力和精力才能让它看起来一模一样？
感谢南桥认证的 Kubernetes 管理员和工程师/团队负责人 Volodya Guryanov，他从一开始就见证并积极参与了许多 Slurm 课程的创建。
他看到了课程创作的弱点——复杂性和棘手的问题、洞察力和意想不到的解决方案。 还有我们已经熟悉的 Kubernetes 强化课程，例如 Slurm Basic 和 Slurm Mega。 以及一门经过大幅修改的新课程 ，它无情地临近，并将于19月XNUMX日开始。
但是，也许歌词已经说得够多了，让我们继续讨论故事本身。 如何从几个密集的主题中形成一个完全自给自足且多方面的主题 。 所以我将从如何创建和开发课程的故事开始 - 就像“很久以前，在一个遥远的星系......”
幕后到底是什么？
如果你问我们如何制作课程以及一切从哪里开始，我会简单地回答“一切都始于一个想法”。
通常这个想法来自某个地方——我们不会被戴上手铐坐在地下室，直到我们想出：“我们应该开设什么主题的课程？” 想法来自外部来源。 有时人们开始主动问：“你对某某特定技术了解多少？” 或者说，对于 Docker 来说，不可能让他适应强化课程的时间——他显然必须被带到外面，以便有时间在强化课程中讲一些东西。
这就是一个想法的出现。
在我看来，宣布之后，最困难的时刻就开始了——总体上理解本课程要包含哪些内容——这与演讲者为任何会议做准备的方式非常相似。
当你似乎选择了一个主题并思考：“我能告诉你什么？ 这太简单了，这是显而易见的，大家也都知道。”
但事实上根本不是这样的。 我个人在很多地方都说过，对于你、那些来听你演讲或参加课程的人来说，看似显而易见的事情其实并不明显。 这里就出现了如此大的工作层次和内部冲突，即课程中包含哪些内容。 结果，我们得到了这样一个章节列表，内容如此笼统，课程将讲述什么内容。
然后简单的日常工作就开始了：
- 材料选择
- 请仔细阅读当前版本的文档，因为 IT 世界现在正在以某种宇宙速度发展。 即使您正在研究某些东西并制作有关它的课程，您也必须查看文档并查看其中的新内容，有哪些值得讨论的内容，以及可能特别有用的内容。
- 课程的某个框架出现了，其中大多数主题一般都已经涵盖了，而且似乎无论有什么 - 录制视频并将其投入生产。
- 但事实上，不，那么艰苦的工作就开始了，但不是针对课程的作者，而是针对那些测试的人。 通常我们的 alpha 测试人员是技术支持人员，首先校对课程中的任何句法和语法错误。 其次，当我们遇到一些完全不明显、难以理解的地方时，他们就会用棍棒打我们，使我们痛苦不堪。 当文本中出现一些结构复杂、长达几页的从属句子或明显的废话时。 他们全部阅读并留意。
- 然后练习测试阶段开始，一些明显的不工作的东西也被捕获，并且显示一些可以变得更加困难的时刻，因为它变得不是很有趣 - 只是坐着和复制 - 并且确定了非常重要的地方困难，我们有很多事情要做，我们希望那些参加这门课程的人能够做到这一点。 然后建议就来了：“伙计们，把这里弄得更简单一些，这样会更容易被感知，也会从中得到更多好处。”
- 做完这么多工作，与视频相关的部分就写好了，一切似乎都顺利了。 您已经可以将其捐赠用于制作、宣传本课程。 但同样，不，现在还为时过早——因为最近我们已经不再相信自己了，原则上，我们已经开始更多地利用反馈进行工作。 有一种东西叫做 beta 测试 - 这是当人们被外部邀请时，与我们公司没有任何联系，并且为了一些好东西，他们会看到课程的所有部分，视频，文本，实践任务，以便他们评估材料的质量、材料的可获取性，并帮助我们使课程尽可能好。
- 当经历几次这样的迭代时，扬声器、技术支持形式的 alpha 测试、beta 测试、改进。 然后一切重新开始——技术支持、beta 测试、改进。
- 在某些时候，我们会认识到，要么我们完成修改，因为确保每个人都喜欢它是完全不现实的，要么做出一些重大决定。 当对某些地方的许多评论很关键时，请在全球范围内重做它们，因为出了问题。
- 然后就到了进行小修改的时候了——在某个地方，句子的表述不太好，在某个地方，有人不喜欢字体 14,5，但想要 15,7。
- 当这种评论仍然存在时，就这样，课程或多或少地打开了，正式销售开始了。
乍一看，创建课程这个简短的任务一点也不简单，而且需要非常长的时间。
还有一点很重要，课程发布后，课程的工作并没有结束。 首先，我们仔细阅读了某些部分留下的评论。 尽管我们付出了所有的努力，但仍然发现了一些缺陷，一些错误正在被实时纠正和改进，以便每个后续用户都能得到更好的服务。
每门课程都有自己的产品负责人，除了定义总体概念外，他还会检查截止日期，并在页边空白处做笔记，表明当需要完全重写课程时，它肯定会到来，因为在两年内，甚至一年后，我们所说的一些内容将变得无关紧要，仅仅因为它们在道德上变得过时。 产品负责人在页边空白处做了笔记，大多数人经常会问哪些要点不清楚，哪些任务看起来非常困难，哪些任务相反看起来非常简单。 所有这些都在重新录制课程时、在某种重构过程中考虑在内，以便全局课程的每次迭代都变得更好、更方便和舒适。
这就是课程的出现方式。
Docker 课程是如何诞生的
这对我们来说是一个单独的、甚至不寻常的话题。 因为一方面，我们本来没有打算这样做，因为很多在线学校都提供它。 另一方面，他本人要求自由，并在我们用 Kubernetes 培训 IT 专家的理念中找到了合理的位置。
从全球范围来看，最初这一切都是从 Kubernetes 课程开始的，在我看来，它是在第一个 Slurm 之后才开始的。 我们收集了反馈，发现许多人想在其他地方阅读有关 Docker 的其他内容，而且一般来说，许多人在不知道 Kubernetes 是什么的情况下就开始学习 Kubernetes 基础课程 .
因此，对于第二个 Slurm，他们制作了一门课程——或者更确切地说，甚至不是一门课程，而是制作了几个关于 Docker 的章节。 他们告诉了一些最基本的事情，这样来强化班的人就不会感到被剥夺，并且通常会理解正在发生的事情。
然后事情的发展大致是这样的。 材料量增加并在 3 天内停止安装。 于是出现了一个合乎逻辑且显而易见的想法：为什么不将我们在 Slurm Basic 中介绍的内容转变为某种小型课程，您可以让想要观看有关 Docker 的人员参加该课程，然后再参加有关 Kubernetes 的强化课程。
事实上，Slurm Junior 就是几门此类基础课程的组合。 结果，Docker 课程成为了 Slurm Junior 的一部分。 也就是说，这之前是这样的零步 и 。 然后只有非常基本的抽象。
在某些时候，人们开始问：“伙计们，这一切都很棒，这足以理解你们在强化课程中谈论的内容。 我在哪里可以更详细地了解 docker 可以做什么、如何使用它以及它是什么？” 所以就想出了一个办法来解决这个问题 这样，一方面，使用 Kubernetes 来 Slurm 的人仍然可以被发送到它，另一方面，对于那些在现阶段对 Kubernetes 甚至不感兴趣的人来说。 这样，IT 专家就可以观看我们的 Docker 课程，并从纯粹的 Docker 开始他的进化之路。 这样我们就有了这样一个成熟、完整的课程——然后很多人在观看了这个课程、使用纯 Docker 工作了一段时间之后，已经发展到了需要 Kubernetes 或其他一些编排系统的水平。 他们特别来找我们。
有时会问：“现在什么样的人可能不需要 Kubernetes？” 但这不是人的问题，而是企业的问题。 这里你需要明白，Kubernetes 在某些情况下非常适合它，并且可以很好地解决任务，但相反，在某些场景下使用 Kubernetes 会带来额外的痛苦和额外的痛苦。 因此，它甚至不取决于人，而是取决于公司发展了什么以及发展了多久。
例如，一些可怕的遗留巨石 - 你可能不应该将其推入 Kubernetes，因为它会导致更多的问题而不是好处。 或者，例如，如果这是一个小项目，那么它的负载就很小，或者原则上没有很多资金和资源。 将其拖到 Kubernetes 中是没有意义的。
一般来说，可能，正如很多人已经说过的那样，如果你问这个问题：“我需要 Kubernetes 吗？”，那么很可能你不需要它。 我不记得是谁第一个提出这个想法的，我认为是帕夏·塞利瓦诺夫（Pasha Selivanov）。 我百分百同意这一点。 你需要成长到 Kubernetes - 当我已经清楚地知道我需要 Kubernetes 并且我们公司需要它，并且它将有助于解决这样那样的问题时，那么去学习并弄清楚如何设置可能是有意义的做好了，这样切换到 Kubernetes 的过程就不会很痛苦了。
孩子的一些小病，一些简单的事情，甚至不是很简单的事情，都可以从我们这里特别找出来，而不用自己去费力和痛苦。
许多公司的做法完全一样，最初只有某种基础设施，没有容器化。 然后他们到了管理这一切变得困难的地步，他们转向了 Docker，在某个时候，他们发展到了在 Docker 及其提供的框架内变得局促的地步。 他们开始研究周围的情况，什么系统可以解决这些问题，特别是 Kubernetes——当纯 Docker 变得拥挤且缺乏功能时，这是一个可以让你解决问题的系统，这是一个非常好的案例，当人们他们从下到上一步步前进，明白这项技术还不够，并进入下一个层次。 他们使用了一些东西，它又变得稀缺了，然后他们继续前进。
这是一个有意识的选择——而且非常酷。
总的来说，我发现我们的系统构建得非常漂亮，例如， ，甚至通过视频课程。 然后在 docker 之后它就走了 ，然后 ，然后 。 一切都按逻辑排列——一个人过去了，一个扎实的职业出现了。
原则上，这套课程可以让你涵盖很多案例，甚至是现代案例。 仍然有一些领域仍然是灰色区域，我希望我们很快会创建一些课程，使我们能够关闭这些灰色区域，特别是我们将提出一些有关安全的内容。 因为这变得非常重要。
简而言之，我们有一些灰色区域，最好关闭它们，这样它就会是一个完整的、完整的图景——人们可以来，就像 Kubernetes 本身就像一个乐高构造器一样，你可以用它来制作不同的东西它收集，如果还不够——补充，和我们的课程一样，让人们从中了解他们需要什么；他们需要从我们的课程中组装出一种拼图，一种构建集。
如果您问自己一个大致正确且诚实的问题：“现在谁可以使用活跃的 Docker 课程？”，那么：
- 对于刚开始接触这个领域的同学来说。
- 测试部门员工。
- 事实上，仍然有很多公司不仅没有使用Docker，而且没有人听说过这种技术，原则上也不知道如何使用它。 而且我知道圣彼得堡的几家大公司已经发展了很多年了，他们使用了一些旧的技术，他们正在朝这个方向发展。 特别是对于这样的公司，对于这样的公司的工程师来说，这个课程可能会非常有趣，因为，首先，它可以让你快速沉浸在这项技术中，其次，一旦有几个工程师出现，他们就知道这一切是如何进行的。工作后，他们可以将其带到公司并在公司内部发展这种文化和这些方向。
- 在我看来，这门课程对于那些已经使用过 docker 的人来说可能仍然有用，但在“做一次，做两次”风格中很少而且更多——现在他们将以某种方式与同一个 Kubernetes 进行交互，而这个对他们施加了一定的义务，如果你对 docker 是什么、如何运行它只有非常肤浅的了解，但同时你不知道它从内部是如何工作的，你不知道最好用什么来处理什么是最好不要做，那么这门课程非常适合系统化和深化知识。
但是，如果您具有以下级别的知识：“我不知道如何正确编写相同的 Docker 文件，我可以想象名称空间是什么，容器如何工作，它们在操作系统级别如何实际实现” - 那么就有了去我们这里绝对没有意义，你不会学到任何新东西，而且你会为所花费的金钱和时间感到有点难过。
如果我们明确我们的课程有哪些优势，那么：
- 我们试图让这门课程有足够数量的实际案例，让你不仅能够理解现有的理论部分，还能理解为什么你需要它以及将来如何使用它；
- 有几个部分在任何地方都很少见——而且一般来说，关于它们的材料并不多。 它们与 Docker 与操作系统的交互有关，甚至略有不同。 Docker 从操作系统中采用了哪些机制来实现容器化系统，这让我们对在 Linux 操作系统中运行容器的整个问题有了更深入的了解。 它如何工作，如何在操作系统内部、外部相互交互，等等。
这是一种真正深入的观察，很少发生，但同时，在我看来，它非常重要。 如果你想很好地理解任何技术并了解它的期望，你至少需要对它在低层次上如何工作有一个总体了解。
我们的课程从操作系统的角度展示并讲述了它是如何工作的。 一方面，所有容器化系统都使用相同的操作系统机制。 另一方面，他们采用了 Linux 操作系统中的东西，比如 docker。 其他容器化系统并没有提出任何新东西——它们采用了 Linux 中已有的东西，只编写了一个方便的包装器，允许您快速调用它、运行它或以某种方式与其交互。 同样的 Docker 并不是操作系统和命令行之间的一个非常大的层，它是一种实用程序，允许您不必编写数千个命令或某种 C 代码来创建容器，而是通过输入来完成此操作终端中的几行。
还有一件事，如果我们具体谈论 Docker，Docker 真正给 IT 世界带来的是标准。 应用程序应该如何启动，应该如何工作，日志有什么要求，扩展有什么要求，配置应用程序本身。
在很多方面，docker 都是关于标准的。
标准也在转向 Kubernetes - 并且有完全相同的标准；如果您知道如何在 Docker 中很好地运行应用程序，那么 99% 的情况下它在 Kubernetes 中也能正常运行。
如果您发现自己不仅对 Docker 课程的创建方式感兴趣，而且对其他课程感兴趣，而且从实践的角度对课程本身感兴趣，那么
我们很高兴见到您！
来源： habr.com