מעבר לפתרון אירוח עצמי מ-Kubernetes

[stevejr (Steve)]

שלום לכולם,

אני מריץ את Discourse בקלאסטר של Kubernetes מזה זמן מה תוך שימוש בתמונת Bitnami שאינה נתמכת. כעת, כאשר Bitnami מפסיקה את התמיכה בתמונה ועוברת למודל בתשלום, אני מחפש להעביר את השרת שלנו לפתרון אירוח עצמי ב-AWS.

יש לי כמה שאלות שהייתי אסיר תודה אם הקהילה תוכל לעזור בהן:

• אנו כבר משתמשים במסד נתונים חיצוני של Postgres עבור ההתקנה, ולכן הוא יישאר במקומו. עם זאת, עדכנו כמה הגדרות דרך הממשק וגם באמצעות משתני סביבה שסקריפטי ההתקנה של Bitnami ממפים ל-Discourse, לדוגמה DISCOURSE_S3_BACKUP_BUCKET ממפה ל-S3_BACKUP_BUCKET.
  • האם מספיק להגדיר את הגדרות Discourse בקבצי ה-yaml הנדרשים או שעלינו עדיין להשתמש במשתני סביבה?
  • אם אנו מבצעים גיבוי מהממשק, מה הוא ישחזר בפועל - האם הוא מעדכן את מסד הנתונים?
  • האם עדיף ליצור מסד נתונים חדש לגמרי עם התקנה נקייה ואז לבצע גיבוי/שחזור?
  • אם ההתקנה החדשה היא גרסה מאוחרת יותר של Discourse, האם זה יגרום לבעיה אם ינסו לבצע שחזור?
• מדריך ההתקנה הסטנדרטי משתמש ב-Docker - כיצד מנטרים את הקונטיינרים בסביבת ייצור מכיוון שנראה שההתקנה הסטנדרטית היא VM יחיד עם Docker.
• האם ישנם מסמכים המפרטים הגירה וכל “מלכודות” אפשריות?

אני בטוח שיהיו לי עוד שאלות ככל שההגירה תתקדם, אך כל עצה/עזרה שניתן להעניק תתקבל בהערכה רבה.

תודה.

[pfaffman (Jay Pfaffman)]

@stevejr

We use an external Postgres DB already for the installation and so this will stay in place.

If it wasn’t already your plan, I’d move to a new database (on the same server) for the migration so you don’t break your existing site.

@stevejr

However, we updated some settings via the UI and also using environment variables that the Bitnami installation scripts maps to the Discourse, for example DISCOURSE_S3_BACKUP_BUCKET maps to S3_BACKUP_BUCKET.

I can’t tell quite what you think Bitnami is doing, but the thing you want in your ENV is DISCOURSE_S3_BACKUP_BUCKET. See Configure an S3 compatible object storage provider for uploads for how to properly set those S3 variables in your app.yml.

@stevejr

Is it better to create a brand new database with a fresh install and then do a backup/restore?

If by “better” you mean “will this mean that I won’t break our existing site and leave it in a state where it will never work again?”, the answer is yes.

@stevejr

Is it good enough to set the Discourse settings in the required yaml files or should we still use env vars?

Set them in the YML

@stevejr

If we do a backup from the UI what will that actually restore - does it update the database?

Yes it will update the database. I would recommend that you Restore a backup from the command line

@stevejr

If the new install is a later version of Discourse will that cause a problem if a restore is attempted?

That’s what you want. The place you restore from has to be the same or newer than the backup version. It’ll migrate the database after it’s restored.

This might be all you need to know and we’re happy to help here for free. If you’d like hands-on your-setup-specific attention, you can contact me or ask for help in Marketplace.

Also, another option would be to build images and launch those in k8s. I’ve done that a few times and used github to build the images.

[manning-ncsa (Andrew Manning)]

@pfaffman

@stevejr

Is it better to create a brand new database with a fresh install and then do a backup/restore?

If by “better” you mean “will this mean that I won’t break our existing site and leave it in a state where it will never work again?”, the answer is yes.

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.

@stevejr

• The standard installation guide uses Docker - how do you monitor the containers in a production environment as it looks like the standard install is a single VM with Docker.

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.