Managed Database
-
Hi all
I’ve agreed to help someone setup a forum, and partly because a threaded view will be useful for more in depth discussions, I think NodeBB is the best of the shortlist. However as the previous forums/websites I’ve created have been hosted on managed web space, and my experience of linux / node.js etc are very basic, I’d like to keep the setup as simple as possible.
For various reasons, it’s necessary to host it on Ionos. I’d like advice on a couple of decisions before I go any further:
- VPS or “Cloud Server”. In terms of ease of management and scalability, I’m assuming that a Cloud Server would be the better option?
- Ionos offer a managed MungoDB service. Any reason not to use an Ionos managed MugoDB?
- Maintenance. It sounds like there are going to be several layers of software installed - linux, node.js, nginx, nodeBB (+ MungoDB) etc. Do all of these need to be updated separately and manually?
- I'm tempted to use the Docker image, but I assume that is likely to be more challenging than a standard install?
Any comments on any of these would be appreciated…
-
@SimonA Let me help you out here. I have vast experience with infrastructure, and also run sudonix.org
My responses below
- VPS or “Cloud Server”. In terms of ease of management and scalability, I’m assuming that a Cloud Server would be the better option?
You'll need a VPS. This will give you ROOT access to a Linux server of your choosing, and will also enable to you build the server as you wish with no restrictions. IONOS often have deals meaning you ca get a server for £1 per month for the first 6 months, and then full price after that - which in most cases is still very cheap. However, for a more comfortable ride, I'd suggest the below at £5 per month
- Ionos offer a managed MungoDB service. Any reason not to use an Ionos managed MugoDB?
Yes, they will likely have restrictions around the version, what you can execute, and there will be an associated cost. My advice would be to install and host your own. PS - I think you mean "Mongo" and not "Mungo"?
- Maintenance. It sounds like there are going to be several layers of software installed - linux, node.js, nginx, nodeBB (+ MungoDB) etc. Do all of these need to be updated separately and manually?
Yes, they do. However, it's not that big a job, and easy once you get to grips with the required technologies.
- I'm tempted to use the Docker image, but I assume that is likely to be more challenging than a standard install?
Yes, it will be. Take my advice, and DON'T do this unless you have a specific need.
-
That's really useful thankyou PL. And yes sorry, MongoDB
In terms of the VPS you have suggested, you have not selected the backup. Is that not high risk with the database on the instance? Or does the database need to be dumped to a flat file separately anyway? This was one of the reasons I was thinking of a managed DB, as usually you can just revert the DB back when necessary...
Also how far will NodeBB scale on a single M VPS server including the DB? The expectation is that is could end up with tens of thousands of users, so potentially a high number of concurrent users? I guess it's always possible to migrate it to a bigger setup later, but do you have any idea what kind of load an M class VPS could handle?
Interestingly I tried using the docker image with AWS ECS Fargate in my test account while I was waiting for a reply here, and the service created an error which I spent the last hour trying to solve. So I'm happy to give up on that approach!
-
@SimonA said in Managed Database:
In terms of the VPS you have suggested, you have not selected the backup. Is that not high risk with the database on the instance? Or does the database need to be dumped to a flat file separately anyway? This was one of the reasons I was thinking of a managed DB, as usually you can just revert the DB back when necessary...
I haven't actually selected anything in that link - it was only a pointer taking you to the VPS section. Of course you'd want to backup - IONOS offerings are typically re-branded Acronis and require the installation of an agent on the VPS before the backup will function. However, despite the server being relatively cheap, IONOS charge by the Gb for storage, so backups can work out to be quite expensive depending on your needs, and if you are predicting the sort of growth you mention, you may want to reconsider IONOS as the provider, and perhaps go for something like Hetzner who offer "storage boxes" than can be used for backup purposes and work out much cheaper in the long run.
@SimonA said in Managed Database:
Also how far will NodeBB scale on a single M VPS server including the DB? The expectation is that is could end up with tens of thousands of users, so potentially a high number of concurrent users? I guess it's always possible to migrate it to a bigger setup later, but do you have any idea what kind of load an M class VPS could handle?
The M series VPS is a very capable server but certainly will not cope with tens of thousands of users. It's certainly extremely capable, and as good sizing option to see where things go without jumping in at the deep end, and if things to take off, you can easily get a larger host by changing the contract to a larger model. The server simply powers down, and when it powers back on, it's the higher model with no data loss. However, be aware that upgrading is a one-way ticket - you can upgrade, but it's not so easy to downgrade as this typically attracts a new contract when the counter reset from the upgrade date.
In terms of the actual figures that an M server will support, I don't have the specifics, but the devs here can easily assist with that one to give you some idea. You'd get a sizable number of users on an IONOS M class server, but unless you already have a guaranteed user base hammering on the door, start small and work upwards rather than vice-versa.
@SimonA said in Managed Database:
Interestingly I tried using the docker image with AWS ECS Fargate in my test account while I was waiting for a reply here, and the service created an error which I spent the last hour trying to solve. So I'm happy to give up on that approach!
Yes, Docker images do work - don't get me wrong, but they are unnecessarily complex and horrible to work with if you encounter errors. The images cut down on the overall administration and offer security out of the box, but if you're comfortable with Linux administration, then the "old skool" way still works - in fact, better in my view.
-
CPU[| 0.5%] Tasks: 39, 0 thr, 18 kthr; 1 running
Mem[|||||||||||||||||||||||||||||||||||||||||| 452M/989M] Load average: 0.03 0.13 0.15
Swp[ 0K/0K] Uptime: 13 days, 12:15:35[Main]
PID USER PRI NI VIRT RES S CPU%▽MEM% TIME+ Command
1 root 20 0 11704 460 S 0.0 0.0 0:00.52 /sbin/init
553 root 20 0 13160 1048 S 0.0 0.1 0:00.01 dhclient: system.syslog
556 root 60 0 13160 1144 S 0.0 0.1 0:00.02 dhclient: vtnet0 [priv]
638 _dhcp 20 0 13164 1360 S 0.0 0.1 0:00.02 dhclient: vtnet0
666 root 20 0 14400 1476 S 0.0 0.1 0:48.60 /sbin/devd
674 root 20 0 13012 820 S 0.0 0.1 0:01.47 /usr/sbin/rtsold -aF
678 root 68 0 13008 780 S 0.0 0.1 0:00.00 rtsold: rtsold.llflags
680 root 26 0 13008 1000 S 0.0 0.1 0:01.19 rtsold: rtsold.script
681 root 24 0 13008 780 S 0.0 0.1 0:00.00 rtsold: rtsold.sendmsg
682 root 20 0 13008 968 S 0.0 0.1 0:00.90 rtsold: system.syslog
903 root 20 0 12880 1272 S 0.0 0.1 0:29.69 /usr/sbin/syslogd -s
948 gotosocial 20 0 12832 660 S 0.0 0.1 0:00.23 daemon: /usr/local/bin/gotosocial[950]
950 gotosocial 68 0 1278M 88604 S 0.0 8.7 6:56.05 /usr/local/bin/gotosocial --config-path /usr/local/etc/gotosocial/config.yaml server start
975 root 20 0 19332 2836 S 0.0 0.3 0:49.54 /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf
990 root 68 0 13380 8 S 0.0 0.0 0:00.00 /bin/sh /usr/local/sbin/sshguard -i /var/run/sshguard.pid
994 root 20 0 12992 1076 S 0.0 0.1 1:38.84 tail -F -n 0 /var/log/auth.log /var/log/maillog
995 root 20 0 17596 2640 S 0.0 0.3 0:03.63 /usr/local/libexec/sshg-parser
996 root 20 0 13508 1440 S 0.0 0.1 0:02.30 /usr/local/libexec/sshg-blocker -a 30 -p 120 -s 1800 -N 128 -n 32
997 root 20 0 13380 1120 S 0.0 0.1 0:00.35 /bin/sh /usr/local/libexec/sshg-fw-pf
1004 root 68 0 13508 1112 S 0.0 0.1 0:00.00 sshg-blocker: system.net
1005 root 68 0 17596 956 S 0.0 0.1 0:00.00 sshg-parser: system.net
1008 root 20 0 12992 528 S 0.0 0.1 1:25.51 tail: system.fileargs
1025 www 68 0 1448M 84808 S 0.0 8.4 8:51.47 /usr/local/bin/caddy run --pingback 127.0.0.1:57243 --config /usr/local/etc/caddy/Caddyfile --adapter
1053 root 20 0 22836 2208 S 0.0 0.2 0:08.82 sshd: /usr/sbin/sshd [listener] 0 of 10-100 startups
1056 root 20 0 12920 636 S 0.0 0.1 0:04.39 /usr/sbin/cron -s
1070 root 68 0 12848 788 S 0.0 0.1 0:00.00 /usr/libexec/getty Pc ttyv0
1071 root 68 0 12848 788 S 0.0 0.1 0:00.00 /usr/libexec/getty Pc ttyv1
1072 root 68 0 12848 788 S 0.0 0.1 0:00.00 /usr/libexec/getty Pc ttyv2
1073 root 68 0 12848 788 S 0.0 0.1 0:00.00 /usr/libexec/getty Pc ttyv3
1074 root 68 0 12848 788 S 0.0 0.1 0:00.00 /usr/libexec/getty Pc ttyv4
1075 root 68 0 12848 792 S 0.0 0.1 0:00.00 /usr/libexec/getty Pc ttyv5
1076 root 68 0 12848 796 S 0.0 0.1 0:00.00 /usr/libexec/getty Pc ttyv6
1077 root 68 0 12848 784 S 0.0 0.1 0:00.00 /usr/libexec/getty Pc ttyv7
14624 root 20 0 23024 9604 S 0.0 0.9 0:00.02 sshd: root@pts/0
14626 root 20 0 14700 4200 S 0.0 0.4 0:00.01 -bash
14628 root 20 0 16616 4532 R 0.0 0.4 0:00.04 htop
45925 root 20 0 679M 57668 S 0.0 5.7 5:22.35 node: PM2 v5.4.2: God Daemon (/root/.pm2)
54965 mongodb 68 0 514M 136M S 0.0 13.8 41:47.30 /usr/local/bin/mongod --logpath /var/db/mongodb/mongod.log --logappend --setParameter=disabledSecureA
95579 root 20 0 9737M 252M S 0.0 25.5 17:41.36 node: node /home/NodeBB/app.js
