从 Kubernetes 迁移到自托管解决方案

大家好,

我已经在 Kubernetes 集群中运行 Discourse 一段时间了,使用的是不受支持的 Bitnami 镜像。现在 Bitnami 即将弃用该镜像并开始收费,我正计划将我们的服务器迁移到 AWS 上的自托管解决方案。

我有几个问题,希望能得到社区的帮助:

  • 我们已经为安装使用了外部 Postgres 数据库,所以它将保持不变。但是,我们通过 UI 和环境变量更新了一些设置,Bitnami 的安装脚本会将这些设置映射到 Discourse,例如 DISCOURSE_S3_BACKUP_BUCKET 映射到 S3_BACKUP_BUCKET
    • 在必需的 yaml 文件中设置 Discourse 设置是否足够,还是应该继续使用环境变量?
    • 如果我们从 UI 进行备份,它实际上会恢复什么?它会更新数据库吗?
    • 是创建一个全新的数据库并进行全新安装,然后进行备份/恢复更好吗?
    • 如果新安装的版本比当前版本更新,在尝试恢复时是否会造成问题?
  • 标准安装指南使用 Docker - 在生产环境中如何监控容器?看起来标准安装是带有 Docker 的单个 VM。
  • 有没有什么文档详细说明了迁移过程以及需要注意的事项?

我相信在迁移过程中我会有更多问题,但任何可以提供的建议/帮助都将非常感激。

谢谢。

如果这还不是你的计划,我建议迁移到一个新数据库(在同一台服务器上),这样你就不会破坏你现有的网站。

我无法确切了解你认为 Bitnami 在做什么,但你想要在你的 ENV 中设置的是 DISCOURSE_S3_BACKUP_BUCKET。请参阅 为上传配置 S3 兼容对象存储提供商 来了解如何在你的 app.yml 中正确设置这些 S3 变量。

如果“更好”的意思是“这是否意味着我不会破坏我们现有的网站并使其处于永远无法工作的状态?”,那么答案是肯定的。 :wink:

在 YML 中设置它们。

是的,它会更新数据库。我建议你 从命令行恢复备份

这就是你想要的。恢复的来源必须与备份版本相同或更新。恢复后,它将迁移数据库。

这可能是你需要知道的一切,我们很乐意免费提供帮助。如果你需要针对你的具体设置进行动手指导,可以联系我或在 Marketplace 中寻求帮助。

另外,另一种选择是在 k8s 中构建镜像并启动它们。我做过几次,并使用 github 来构建镜像。

My experience concurs. I have seen so many strange little failures over the years that I always maintain full backups such that I can start from scratch and restore the site. Relying on fixing problems in situ will eventually fail you.

Like you, I was left in the lurch when Bitnami stopped offering free images and charts. I had to adapt and migrate so many deployments. One of them was my Discourse deployment. If it is useful to you, here is a link to the replacement Helm chart I created in a very short amount of time (meaning that it works but is far from an ideal design). It is an attempt to use the “official installation method” given that I have seen no “community standard” Helm chart emerge after all these years. (I suppose Bitnami’s chart was effectively that standard, because few of us predicted this abrupt change.) In any case, this new chart that I am running for one of my research communities is basically just a pod with two containers: the official Docker-in-Docker container and a custom container based on python:3, installing Docker and then using the official Discourse installation. Because all the components (Discourse server, Redis, PostgreSQL) run in the black box of the locally image built by the launcher script, there is no scalability or support for high-availability. I did manage to reduce the downtime due to the pod respawning on another node (e.g. when draining node for OS updates or a node crash) by using docker save to store the built image on the persistent volume, and then loading that if local_discourse/app:latest is not found.

But to answer your question, I do not know how to monitor anything in this new deployment. I am running “in production” but my community is small enough and the usage moderate enough that if the forum goes offline for a while, it is not a big deal. Even so, I am very close to abandoning self-hosting and migrating to a service like Communiteq or Discourse.org.

My experience concurs. I have seen so many strange little failures over the years that I always maintain full backups such that I can start from scratch and restore the site. Relying on fixing problems in situ will eventually fail you.

Like you, I was left in the lurch when Bitnami stopped offering free images and charts. I had to adapt and migrate so many deployments. One of them was my Discourse deployment. If it is useful to you, here is a link to the replacement Helm chart I created in a very short amount of time (meaning that it works but is far from an ideal design). It is an attempt to use the “official installation method” given that I have seen no “community standard” Helm chart emerge after all these years. (I suppose Bitnami’s chart was effectively that standard, because few of us predicted this abrupt change.) In any case, this new chart that I am running for one of my research communities is basically just a pod with two containers: the official Docker-in-Docker container and a custom container based on python:3, installing Docker and then using the official Discourse installation. Because all the components (Discourse server, Redis, PostgreSQL) run in the black box of the locally image built by the launcher script, there is no scalability or support for high-availability. I did manage to reduce the downtime due to the pod respawning on another node (e.g. when draining node for OS updates or a node crash) by using docker save to store the built image on the persistent volume, and then loading that if local_discourse/app:latest is not found.

But to answer your question, I do not know how to monitor anything in this new deployment. I am running “in production” but my community is small enough and the usage moderate enough that if the forum goes offline for a while, it is not a big deal. Even so, I am very close to abandoning self-hosting and migrating to a service like Communiteq or Discourse.org.

2 个赞