有一天，我决定写一篇关于以容器形式交付docker和deb软件包的文章，但是当我开始工作时，由于某种原因，我在第一台个人计算机甚至计算器的遥远日子里遭受了痛苦。 总的来说，这些不是关于docker和deb的干式比较，而是关于进化的想法，我将这些想法呈现给您。
任何产品，无论是什么产品，都必须以某种方式到达产品服务器，并且必须对其进行配置和启动。 本文将对此进行讨论。
我将在历史背景中反映“我所看到的-我唱歌”，当我开始编写代码时所看到的内容以及我现在正在观察的内容，我们自己目前正在使用的内容以及原因。 本文并不假装是一项全面的研究，缺少了一些要点，这是我对过去和现在的看法。
因此，在过去的好日子里……我发现的最早的传送方法是使用盒式磁带。 我有一台计算机BK-0010.01 ...
计算器时代
不，有一个更早的观点，还有
MK-61和
MK-52计算器。
因此，当我拥有
MK-61时 ，传输程序的方法是在记录程序的盒子中使用普通纸，如果需要，可以将其手动写入计算器。 如果您想玩（是的，即使这个古老的计算器上有游戏），您也可以坐下来并在计算器中输入程序。 自然，当计算器关闭时，该程序被遗忘了。 除了个人写在纸上的计算器代码外，这些程序还发布在《青年广播与技术》杂志以及当时的书籍中。
下一个修改是
MK-52计算器，它已经出现了某种非易失性数据存储。 现在，无需手动驱动游戏或程序，但是通过按钮完成了一些魔术操作后，它便自动加载了。
计算器中最大程序的容量为105步，MK-52中永久存储器的大小为512步。
顺便说一句，如果有这些计算器的粉丝正在阅读本文-在撰写本文的过程中，我发现既有适用于Android的计算器模拟器，也有适用于该程序的程序。 转发过去！
关于MK-52的一点题外话 （来自Wikipedia）
MK-52乘坐联军TM-7航天器飞入太空。 如果车载计算机出现故障，应该使用它来计算着陆轨迹。
自1988年以来，带有内存扩展单元“ Electronics-Astro”的MK-52作为导航计算套件的一部分提供给海军舰船。
第一台个人电脑
让我们回到
BK-0010的时代。 显然那里有更多的内存，不再是从纸上驱动代码的选项（尽管起初我只是这样做，因为根本没有其他介质）。 软件存储和交付的主要手段是录音机的录音带。
盒式磁带上的存储通常以一个或两个二进制文件的形式进行，其他所有内容都包含在其中。 可靠性很低，我不得不保留2-3个程序副本。 加载时间也不令人满意，发烧友们尝试了不同的频率编码以克服这些缺点。 那时，我本人还没有从事专业软件开发（除了简单的基本程序），因此，不幸的是，我不会详细告诉您内部的所有内容。 大多数情况下，计算机上只有RAM的事实决定了数据存储方案的简单性。
可靠的大型存储介质的出现
后来出现了软盘，简化了复制过程，并提高了可靠性。
但是只有当足够大的本地存储以HDD形式出现时，情况才会发生巨大变化。
交付的类型从根本上发生了变化：安装程序似乎可以控制系统配置过程以及删除后的清理工作，因为程序不仅被读入内存，而且已经被复制到本地存储中，您需要能够从中清除这些程序，并且在必要时不需要这些程序。
同时，所提供软件的复杂性增加。
交付中的文件数量从单位增加到成千上万个，当不同的程序使用相同的数据时，库版本的冲突和其他乐趣就开始了。
在那些日子里，Linux的存在尚未对我开放，我生活在MS DOS和后来的Windows的世界中，并用Borland Pascal和Delphi编写，有时浏览C ++。 为了在
那时提供产品，许多人都使用InstallShield
ru.wikipedia.org/wiki/InstallShield ，它非常成功地解决了部署和配置软件的所有任务。
网络时代
逐渐地，软件系统的复杂性变得更加复杂，从单一的桌面应用程序开始向分布式系统，瘦客户机和微服务过渡。 现在，您不仅需要配置一个程序，还需要配置它们的集合，以便它们成为朋友。
观念已经完全改变，互联网已经来临，云服务时代已经来临。 到目前为止，它只是在初期以网站的形式进行解释，没有人梦到特别是对服务的梦想。 但这是应用程序开发和实际交付行业的一个转折点。
就我自己而言，我注意到此时此刻开发人员的世代发生了变化（或者仅在我的环境中），我感到所有好的旧交付方法一时被遗忘了，一切都从一开始就开始了：他们开始进行整个交付剧本高高在上，并自豪地称之为“连续交付”。 实际上，一个混乱的时期开始了，当旧的事物被遗忘而不被使用时，却根本没有新事物。
我记得当时我在公司工作的时候（我不会打电话），而不是通过蚂蚁来构建（maven尚未流行或根本没有），人们只是在IDE中收集jar并提交svn中的他。 因此，部署是从SVN获取文件，然后通过SSH将其复制到所需的计算机。 如此简单笨拙。
同时，通过将更正的文件通过FTP复制到目标计算机上，将简单站点交付到PHP变得相当原始。 有时没有这种事情-代码是在产品服务器上实时编辑的，如果某处有备份，这是特别时髦的。
RPM和DEB软件包
另一方面，随着Internet的发展，类似UNIX的系统开始变得越来越流行，尤其是那时，我是在2000年左右发现RedHat Linux 6的。 自然地，那里有某些软件交付工具，据Wikipedia称，作为主要软件包管理器的RPM早在1995年就出现在RedHat Linux 2.0版本中。 从那时到现在，该系统已经以RPM软件包的形式交付，并且相当成功地存在和开发。
Debian家族的发行版采用类似的方式，并以deb软件包的形式实现了交付，这一过程至今仍未改变。
软件包管理器允许您自己交付软件产品，在安装过程中对其进行配置，管理不同软件包之间的依赖关系，删除产品以及在卸载过程中清除多余的产品。 即 在大多数情况下，这就是所需要的，这就是为什么它们能够持续数十年而几乎没有变化的原因。
不仅从物理介质而且从云存储库向软件包管理器安装添加了云，但是几乎没有什么变化。
值得注意的是，目前在避免deb并切换到snap软件包方面存在一些麻烦，但稍后会更多。
因此，新一代的不了解DEB或RPM的云开发人员也成长缓慢，积累了经验，产品变得更加复杂，并且需要比FTP，bash脚本和类似学生手工艺品更为合理的交付方式。
Docker进入了现场，一种虚拟化，资源分配和交付方法的混合体。 它现在很年轻，很时髦，但是所有东西都需要它吗？ 是灵丹妙药吗？
根据我的观察，提供Docker并不是一个合理的选择，而仅仅是因为一方面，它是在社区中谈论的话题，而提供Docker的人只知道它。 另一方面，在大多数情况下，他们对好的旧包装系统保持沉默-他们过去和现在都在悄悄地，无意识地进行工作。 在这种情况下，别无选择-选择是显而易见的-Docker。
我将尝试分享有关我们如何实现Docker以及由此发生的事情的经验。
自写脚本
最初，有bash脚本将jar存档部署到必要的计算机上。 由詹金斯（Jenkins）管理此过程。 这成功完成了，因为jar存档本身已经是一个包含类，资源甚至配置的程序集。 如果您将所有内容都发挥到最大-然后使用脚本对其进行扩展-这不是您最困难的事情
但是脚本有几个缺点：
- 脚本通常是匆忙编写的，因此太原始了，以至于它们仅包含最成功的脚本之一。 开发人员对快速交付感兴趣，并且正常脚本需要大量资源，这一事实使这变得容易。
- 作为上一段的结果，这些脚本不包含卸载过程
- 没有确定的升级程序
- 当出现新产品时，您需要编写新脚本
- 没有依赖支持
当然，您可以编写一个精美的脚本，但是，正如我上面所写的，这是开发时间，而不是最小的时间，但是，正如您所知，总是没有足够的时间。
所有这些显然将这种部署方法的范围限制为最简单的系统。 是时候改变这一点了。
码头工人
在某个时候，新鲜出炉的中间物开始出现在我们的脑海中，带着想法沸腾，并与码头工人狂欢。 好吧，手中的旗帜-做到这一点！ 有两次尝试。 两者都不成功-可以这么说，因为雄心勃勃，但缺乏实际经验。 是否有必要以任何方式强迫和结束？ 不太可能-团队必须逐步发展到所需的水平，然后才能使用适当的工具。 最重要的是，使用现成的Docker镜像，我们经常会遇到这样一个事实，即网络在此处无法正常工作（这也可能与Docker本身的潮湿程度有关），或者很难扩展其他人的容器。
我们遇到了什么不便？
- 桥接模式下的网络问题
- 查看容器中的日志很不方便（如果未将日志放在主机文件系统之外的任何位置）
- 定期将奇怪的ElasticSearch挂在容器内，原因尚未成立，容器是官方的
- 在容器内使用外壳很尴尬-一切都经过了精心修剪，没有熟悉的工具
- 收集大容器-储存昂贵
- 由于容器的尺寸较大，因此很难支持多个版本
- 与其他方法（脚本或deb软件包）不同，构建时间更长
另一方面，通过同一deb以jar存档的形式部署Spring服务是否更糟？ 真的需要资源隔离吗？ 丢掉操作系统的便捷工具，将服务塞进一个经过修剪的容器中，是否值得？
如实践所示，实际上这不是必需的，在90％的情况下，deb程序包就足够了。
好旧的deb何时仍会失败，我们何时真正需要docker？
对我们来说，这是在python中部署服务。 机器学习需要大量的库，而在操作系统的标准交付中则不可用（以及存在错误版本的库），带有设置的黑客行为，针对位于同一主机系统上的不同服务的不同版本的需求导致了供应这种核混合物的唯一合理方法是码头工人。 事实证明，组装docker容器的复杂性要比将它们全部打包到具有依赖项的独立deb软件包中的思想要低，而且没有人会想到这一点。
计划使用docker的第二点是使用蓝绿色部署方案来部署服务。 但是在这里，我想逐渐增加复杂性：首先，收集deb软件包，然后从中组装一个docker容器。
捕捉包
返回快照包。 它们首先正式出现在Ubuntu 16.04中。 与通常的deb软件包和rpm软件包不同，snap包含所有依赖项。 一方面，这避免了库的冲突，另一方面，这意味着结果包的大小更大。 此外，这可能会影响系统的安全性：在快速交付的情况下，对所包含库的所有更改应由创建软件包的开发人员进行监视。 通常，并非所有事物都那么简单，并且使用它们的普遍幸福并没有到来。 但是，如果仅将同一个Docker用作封装而不是虚拟化，则这是一个相当合理的选择。
结果，我们现在以合理的组合使用了deb软件包和docker容器，在某些情况下我们可以用snap软件包代替它们。