从 cPanel 切换到站点工具的状态报告

[shukla7789]

目录

移民的内在复杂性
多个附加域使用同一个数据库
配置中具有绝对路径的应用程序
附加组件/停放/子域名无限设置选项
严肃的开发任务
实现所有可能的流程自动化
首先切换到新客户专区
2020 年的挑战
转移到Google云平台
COVID-19 的影响
迁移的当前状态
距离我们推出新的客户界面（改进的客户 乌干达 whatsapp 数据 区和内部开发的取代 cPanel 的站点工具）已经过去了一年多的时间。2019 年 8 月，我们开始让所有新客户使用新界面，不久之后，我们开始着手迁移现有客户。截至目前，我们所有的客户都在使用新的客户区，我们还成功将 9000 多台服务器从 cPanel 转换为站点工具。

回顾过去 12 个月，评估转移过程的复杂性以及 2020 年摆在我们面前的非转移相关挑战，我相信我们已经设法保持了健康的迁移速度。这要归功于所有参与转移的团队的大量工作，尽管偶尔会因各种情况而放缓。

尽管如此，我们还有很多帐户和服务器需要转换，你们中的许多人可能想知道为什么需要花费时间，什么时候轮到你们的网站。这就是为什么我们决定进行跟踪，并告诉你们我们在过去一年中幕后做了什么，以及未来几个月的预测是什么。

移民的内在复杂性
将超过一百万个实时网站从 cPanel 迁移到 Site Tools 是一个极其复杂的过程，这并不奇怪。我可能会说，在创建新界面和系统本身所需的努力和资源方面，这几乎是相当的。将运营网站从一个具有特定结构的平台迁移到一个具有完全不同结构的新平台，而不影响这些网站的可用性和功能，这是一个相当大的挑战。

从表面上看，这两个框架之间似乎只有一个简单的区别——没有一个插件站点。这实际上意味着我们必须能够从主 cPanel 帐户中解开任何下属站点，并在新平台中将它们重新创建为单独的独立帐户。为了说明这个过程对于不同的网站设置有多么复杂，我将在下面列出几个示例：

多个附加域使用同一个数据库
通常情况下，这种情况是不合理的，因为每个网站（即使是插件网站）都应该使用自己的数据库。但是，这在 cPanel 上是技术上可行的，而且我们的客户确实以这种方式设置了网站。当需要迁移此类网站时，我们的迁移脚本必须检测到这种情况并为每个网站创建单独的数据库并复制数据。之后，脚本会自动重新配置每个网站以使用相应的数据库。

配置中具有绝对路径的应用程序
迁移脚本应解决的另一件事是多个应用程序在其配置中设置为使用绝对路径。系统必须检测这些应用程序，一旦它们成为具有不同系统用户的独立站点，就自动重新配置它们以使用新的系统路径。

附加组件/停放/子域名无限设置选项
在使用 cPanel 中的插件、停放和子域功能时，用户可以通过无数种方式为不同的应用程序设置文档根路径，有时甚至会弄乱这些路径，这是我们转移过程中面临的最大挑战。我们列出了 30 多种不同的非正统文档根路径案例。最常见的示例之一是将多个插件域配置为使用同一个文件夹。

这是 cPanel 系统常见的“黑客攻击”，人们用它来将第二个域名停放在附加站点 — cPanel 官方不允许这种做法。因此，在这样的设置中，系统必须自动决定每个域名将转到哪个站点以及以什么角色（主站点或停放站点）运行。在某些情况下，设置非常复杂，无法自动配置域名，因此必须手动进行迁移。

严肃的开发任务
实现所有可能的流程自动化
我们去年 9 月非常谨慎地开始了第一次迁移。迁移的网站都经过了人工审查，上面描述的每个问题以及出现的许多其他问题都已通过迁移脚本的新迭代得到解决。毋庸置疑，第一次迁移的人工检查花费了大量时间，而且从长远来看是不可持续的，因此我们在迁移脚本中添加了几个额外的自动化功能。