Creating a Dockerfile

[CloudArtAdmins]

Hello 0perationPrivacy. On my fork, I'm making a Dockerfile for this application. (I just like to maintain all my servers in containers) I am not familiar with nodejs, though, so would you mind if I asked you questions here to help containerize this and possibly give you a merge request, later?

If not, feel free to close this issue.

[0perationPrivacy]

Sure, I'm not familiar with docker files. So it will be an education process for me as well. We can take this offline as a side project. The purpose of keeping the code open in Node was to sync it with Heroku (or any other PaaS) and a db to make it easy and free to self host. Minimize the learning and deployment process for the common user.

[CloudArtAdmins]

I understand it would be more than is intended. Making a containerized setup would be more for people wanting to self host this, like me. How would you want to communicate offline? If email works, you could send me an email farrah (at) cloudart dot moe.

[selfroasted]

ontainerized setup would be more for people wanting to self host this, like me. How would you want to communicate offline?

If you end up doing anything with the Dockerfile, let me know. I'd love to be smart enough to containerize this on my own!

[CloudArtAdmins]

ontainerized setup would be more for people wanting to self host this, like me. How would you want to communicate offline?

If you end up doing anything with the Dockerfile, let me know. I'd love to be smart enough to containerize this on my own!

Making the dockerfile is easy, actually. Already made it on my fork: https://github.com/Farrahs-Cloud-Art/Containerized_VoIP Integrating it with mongo and knowing what needs to be done on the node side is the hard part, but just because I have not worked with a nodeJS server before. Once the "self hosted" option is documented, I'll be able to finish it easily.

Also: thank you, @privacyosint , that will make referencing back to this issue easier.

[slfhstr]

containerized setup would be more for people wanting to self host this, like me.

Like me ! It's fine to have privacy tools, but then to place them on public mongo and heroku seems wrong to me. Understand the thinking and the logic. But much better to have a good-self-host option.

Once the "self hosted" option is documented, I'll be able to finish it easily.

What do you consider the status of your Dockerfile package ?

[CloudArtAdmins]

The dockerfile itself works, as far as I can tell. Just connecting it to mongo-db and such is what I'm not currently familiar with.

[bioscopic]

@CloudArtAdmins do you have a step by step for setting up the VoIP solution with your modification/dockerfile? What does your environment you are hosing this on look like? Are you running a bare metal server with Ubuntu server, Virtual machine, VPS, etc? What parameters in your code if it was forked would need to be modified if any to adapt it for others who would fork it? Are you using docker-compose or docker? Would like to self host this also or at least have the option of doing so in the future. Thanks for any insights you can provide! Thanks for doing this also!

[slfhstr]

The dockerfile itself works, as far as I can tell. Just connecting it to mongo-db and such is what I'm not currently familiar with.

I think the connection to db is frequently setup by creating a docker-compose.yml with a db service specified. How the underling app code needs to change to support this, I am not sure. I can't see easily the db connection the app.

[slfhstr]

I'm not sure why this app needs such a heavy-weight db as Mongo. sql-lite should be sufficient and much more easily integrated.

The repo https://github.com/pawelmalak/flame might give some clues on how to package this app with a db

Sorry, my docker skills are just in deploying, not in creating

[CloudArtAdmins]

@CloudArtAdmins do you have a step by step for setting up the VoIP solution with your modification/dockerfile?

Actually, at the moment, all one needs to do is build the image. I forget how one does it with docker, but for me it would just be buildah bud Dockerfile Then run it with <docker/podman> run <image ID>. Yeah, ports will need exposing, but first the app should get connected to the DB, because it isn't usable without database anyway.

What does your environment you are hosing this on look like? Are you running a bare metal server with Ubuntu server, Virtual machine, VPS, etc?

This is using containers, so my environment is "in containers". Not sure I understand this question.

What parameters in your code if it was forked would need to be modified if any to adapt it for others who would fork it?

Don't know, yet. I need to figure out how to connect this to a MongoDB first.

Are you using docker-compose or docker?

Neither. I'm using Podman. Works almost exactly the same in most cases, though. (one can alias docker to podman and it should still work)

Would like to self host this also or at least have the option of doing so in the future. Thanks for any insights you can provide! Thanks for doing this also!

You and me both...! Of course.

I think the connection to db is frequently setup by creating a docker-compose.yml with a db service specified.

Correct. MongoDB has environment variables for doing this on their docker image's page. The question is "What our 'VoIP' app needs/what does Heroku use?".

How the underling app code needs to change to support this, I am not sure. I can't see easily the db connection the app.

I don't think underlying code needs to be changed, of it does, I don't believe by much... perhaps adding a script or something.

I'm not sure why this app needs such a heavy-weight db as Mongo. sql-lite should be sufficient and much more easily integrated.

Usually, sql-lite, such as the name implies, is meant for relatively basic usage. Full-on databases are used more because those can properly scale, as far as I'm aware. Also, OperationPrivacy mentioned wanting to use mongoDB because dumping the data would be more difficult (or more difficult to sort through, I forget) than an SQL dump.

The repo https://github.com/pawelmalak/flame might give some clues on how to package this app with a db

Actually, yeah, this may help. I haven't gotten an example nodejs images, yet so hopefully this can help me figure out our options.

Sorry, my docker skills are just in deploying, not in creating

I understand. Use to be my case.

[0perationPrivacy]

Mongodb is not only light weight, it is way more secure. Look at the OWASP Top 10, SQL injection attacks have always been in the top-3 for over a decade. MongoDB is a NOSQL database, sure there's a possibility of a NOSQL attack, but it's so low that it doesn't even make the cut in the OWASP list. And for such an attack you need to modify code, host it and have someone use it. In existing self-hosted compilations of running code, this vulnerability is EXTREMELY low.

Mongodb is also LESS complex than SQL, more scalable and easier to install and get running in no time. No creating tables beforehand, no complex joins or lookup queries, no defining ANY structure. If I want to add a new field, i simply add it in the object without affecting any "tables" and without re-indexing and creating another row in a table and potentially breaking and redoing the whole application.

Imagine a table with a million rows, then you add just one more column, you just added a field to a million rows. In mongodb, you only add a field to whichever document requires it, saves a lot of space, and complexity and less disruptive to structure.

When first developing this app, I had mongodb running on localhost. With almost zero knowledge of mongodb when I started, it took me 5 mins to get up and running.

The code doesn't need any modifications if you change the location of the db from cloud to local, just change the environment variable and point it to localhost, which is the default anyways.

The reason I prefer a cloud based db is the MAJORITY of users want it to be easy and quick to set up. With mongodb.com, you don't worry about databases setup, backup, uptime, etc. With self hosted db, if anything goes wrong, there's a lot of troubleshooting for the average tech user and very hard to help out in a forum. That being said, it will work, I just don't have the time to test it. Feel free to document the steps.

With Heroku, it's also easy to host it (I chose it because it's popular and has a free tier, you could replicate it with any other PaaS provider). Self hosting on a VPS or your own server requires additional knowledge of firewalls, NAT, ports, linux commands, DNS entries, etc as you are responsible for configuring the "infrastructure" (vs the PaaS).

Overall, there are hundreds of ways to do this (just look at all the other messaging apps, signal, wire, element, whatsapp), there's no right or wrong way.

Regarding privacy, this is sms, there's no expectation of privacy anyways. This can never be end-to-end-encrypted, it goes through the carrier. We're just cutting the middle-party, taking some control of our own data and decreasing dependence on them. (Sorry for the long answer.)

[ghost]

@0perationPrivacy

if your architecture is secure by design sql or nosql attack surfaces are minimal at best. but in this case mongodb is a good design choice considering the ease of development and not having to be concerned with strict sql trappings and structure.

i do not disagree that a hosted database or heroku to launch this application is a bad idea, but i do agree with others that having a stack where this can be easily deployed would be valuable for your initiatives, particularly with the homelab and self-hosted crowd.

i believe @CloudArtAdmins has started to make headway on a dockerized version of this application. i cloned it and it would not build properly as the node modules are not getting picked up which when trying to build raises multiple exceptions related to the modules that the application requires.

i've started work on a docker-compose setup that will allow the application to be dropped onto a single docker host, single or multi-node docker swarm, or kubernetes where i'm currently testing. if you'd like to add this to the project list and it's something your group decides on i can put this together for public consumption.

[0perationPrivacy]

I've test this on a linux machine with local mongodb running, everything builds and runs fine, only then do I change the db parameter string to the cloud version and host it online. There's a front-end and a backend code, you're probably not compiling the front-end and only the backend. It pretty modular and should be easy to host pretty much anywhere, all you need is a node.js environment. Once I go through all the milestones and app, I will definitely get to an easy packaged way of self hosting the db as well.

Keep in mind, there HAS to be an online cloud component. If your local infrastructure is not available because you host at home, sms delivery is lost. So it's NOT a bad thing to host it in the cloud, it's actually preferred unlike most applications. Especially if you want to sync it in the future between the web version and the app. And with other online features coming up soon (email and voip calling) it will be a pain in the b*tt to open ports and allow syncing between email, voip, sms, mms storage, db, web app, apk, etc if it's all locally hosted. You can't host all those things and maintain them locally, not for the masses at least. BUT the option is there, there's nothing restricting in the code to allow that, in fact, everything is actually tested locally first.

[slfhstr]

Self-hosting is not exactly and always the same as local hosting. If I self-host this app, I would put it in on a VPS 'in the cloud' with a local mongo db on the VPS. Putting the app and mongo in a docker deployment would cut Bazzell's 1 hour install process to 15 mins, and eliminate a lot of support & maintenance issues.

[0perationPrivacy]

@timconsidine I agree, that would be ideal. Unfortunately I have no experience in developing or packaging for docker. Any help there would be appreciated. Feel free to "make it happen". I'll gladly test it out once you iron out the process. Until then, I'll work on building the app further. Thanks.

[ghost]

@timconsidine indeed. perhaps the issue title should be changed to alternative deployment method

@0perationPrivacy yip, it's problematic if a service requires and endpoint to remain alive and self-hoster loses their connectivity. ultimately packaging the application with docker-compose allows an engineer of any sort to have a portable development and deployment environment. i can spike this if you'd like to put it as low-level milestone

sidenote: i'm keen on this application because it has the potential to make bidirectional sms over api easier if you want a bit more privacy versus having baseband beaconing your location

[slfhstr]

perhaps the issue title should be changed to alternative deployment method Yes probably

I just realised this morning that maybe one route to self-host this is to use LXC, create a LXC container and deploy there, point a nginx reverse proxy to it. IN that scenario it would be good to host the mongo db in that LXC container, so no need of Heroku or hosted db. Like your own local development. I will look into this.

Docker will definitiely make it easier for people wanting to self-host on a VPS, but it is not the only way.

[ghost]

@timconsidine in my proof of concept i have mongo and node dockerized and traefik is the reverse proxy which handles ingress and routing. so far it works fine minus some of the node module inclusion within the dockerfile.

lxc is an option, but i'm not sure most users are going to be using lxc and many have significantly more domain knowledge of docker vs lxc. we can do both and provide multiple deployment methodologies.

[slfhstr]

So LXC created and app installed. Will post HOW-TO step by step if anyone is interested. But for now app won't start with npm start

connection error: { MongoParseError: Invalid connection string
    at parseConnectionString (/root/VoIP/node_modules/mongodb/lib/core/uri_parser.js:575:21)
    at connect (/root/VoIP/node_modules/mongodb/lib/operations/connect.js:282:3)
    at cb (/root/VoIP/node_modules/mongodb/lib/mongo_client.js:260:5)
    at maybePromise (/root/VoIP/node_modules/mongodb/lib/utils.js:692:3)
    at MongoClient.connect (/root/VoIP/node_modules/mongodb/lib/mongo_client.js:256:10)
    at Promise (/root/VoIP/node_modules/mongoose/lib/connection.js:835:12)
    at new Promise (<anonymous>)
    at NativeConnection.Connection.openUri (/root/VoIP/node_modules/mongoose/lib/connection.js:832:19)
    at _mongoose._promiseOrCallback.cb (/root/VoIP/node_modules/mongoose/lib/index.js:351:10)
    at Promise (/root/VoIP/node_modules/mongoose/lib/helpers/promiseOrCallback.js:32:5)
    at new Promise (<anonymous>)
    at promiseOrCallback (/root/VoIP/node_modules/mongoose/lib/helpers/promiseOrCallback.js:31:10)
    at Mongoose._promiseOrCallback (/root/VoIP/node_modules/mongoose/lib/index.js:1149:10)
    at Mongoose.connect (/root/VoIP/node_modules/mongoose/lib/index.js:350:20)
    at Object.<anonymous> (/root/VoIP/config/db.config.js:3:10)
    at Module._compile (internal/modules/cjs/loader.js:778:30) name: 'MongoParseError' }
(node:14159) UnhandledPromiseRejectionWarning: MongoParseError: Invalid connection string
    at parseConnectionString (/root/VoIP/node_modules/mongodb/lib/core/uri_parser.js:575:21)
    at connect (/root/VoIP/node_modules/mongodb/lib/operations/connect.js:282:3)
    at cb (/root/VoIP/node_modules/mongodb/lib/mongo_client.js:260:5)
    at maybePromise (/root/VoIP/node_modules/mongodb/lib/utils.js:692:3)
    at MongoClient.connect (/root/VoIP/node_modules/mongodb/lib/mongo_client.js:256:10)
    at Promise (/root/VoIP/node_modules/mongoose/lib/connection.js:835:12)
    at new Promise (<anonymous>)
    at NativeConnection.Connection.openUri (/root/VoIP/node_modules/mongoose/lib/connection.js:832:19)
    at _mongoose._promiseOrCallback.cb (/root/VoIP/node_modules/mongoose/lib/index.js:351:10)
    at Promise (/root/VoIP/node_modules/mongoose/lib/helpers/promiseOrCallback.js:32:5)
    at new Promise (<anonymous>)
    at promiseOrCallback (/root/VoIP/node_modules/mongoose/lib/helpers/promiseOrCallback.js:31:10)
    at Mongoose._promiseOrCallback (/root/VoIP/node_modules/mongoose/lib/index.js:1149:10)
    at Mongoose.connect (/root/VoIP/node_modules/mongoose/lib/index.js:350:20)
    at Object.<anonymous> (/root/VoIP/config/db.config.js:3:10)
    at Module._compile (internal/modules/cjs/loader.js:778:30)

I created a database called localhost which I think is required from looking at /config/db.config.js but maybe I am looking at the wrong thing.

Once I have got the app starting I will create the reverse proxy to reach from a url

[CloudArtAdmins]

@timconsidine Do you have this kept in a public repo, so we can work on the same thing? I'd say that I'm interested in the HOW-TO, but it seems like you are a bit further ahead than I've gotten.

[slfhstr]

@CloudArtAdmins I haven't made repo yet, because I haven't got it working. But will do once I do !

[bioscopic]

@timconsidine thanks im interested in the HOW-TO step by step and can contribute to this!

[0perationPrivacy]

I created a database called localhost which I think is required from looking at /config/db.config.js but maybe I am looking at the wrong thing.

The db sting is taken from .env file. Change it there to the full path of your db. the localhost part is the domain, you need to add the db name after that like you do when it's on mongodb.com

[slfhstr]

Thank you @0perationPrivacy Sorry I don't know anything about mongodb.com and installed mongodb in the Ubuntu container. Could I ask what the syntax would be : localhost/admin ??? I will try some hacking around but if you have an example syntax, that would be very helpful.

[0perationPrivacy]

@timconsidine check this out: https://docs.mongodb.com/manual/reference/connection-string/#examples-1

mongodb://username:password@localhost/dbname

[slfhstr]

Yay ! Thanks for your help @0perationPrivacy App connects to database and launches Apps runs in LXC container on VPS Loads over internet in browser from local machine (mac)

Will post a HOW-TO later this evening.

Now to use the app and get Telnyx number connected (have one ready, just need to provision).

I realise this may not help much with getting a Docker install going, but at least it can be one form of containerisation for self-hosters.

[bioscopic]

@timconsidine great work!

Where will you post the HOW-TO? Do you think it should run smooth for Linux users? Will any commands need to be adapted for those running Linux? or will it be out of the box compatible? Not at all familiar with LXC.

[0perationPrivacy]

Note that notifications and updates to the actual sms work on webhooks. If there's a firewall, you must allow webhooks (inbound) from telnyx and twilio otherwise you wont receive any communications.

[slfhstr]

Note that notifications and updates to the actual sms work on webhooks. If there's a firewall, you must allow webhooks (inbound) from telnyx and twilio otherwise you wont receive any communications.

Ah. That is probably why nothing inbound yet. I have a Telnyx number which routes inbound to a database via a webhook using n8n. I haven't set up webhooks for this app yet. Will look into that.

But also I cannot send out via the app at the moment. Telnyx API key installed and it finds the number ok. But send dialogue "hangs" presumably waiting for a response from some component.

[slfhstr]

@timconsidine great work!

Where will you post the HOW-TO? Do you think it should run smooth for Linux users? Will any commands need to be adapted for those running Linux? or will it be out of the box compatible? Not at all familiar with LXC.

I will post a message here (if that's ok) with a link.

Yes it should be fine with Linux. The VPS is running Ubuntu 20.04 as is the LXC container. I'm quite new to LXC so someone will criticise my inaccurate language but it's kinda like a VM inside your normal linux box, bare metal or VPS. LXC is installed in many distros 'out the box', or it is certainly on Ubuntu 20.04 You can test if you have it already by lxc --version and lxd --version. I will add a couple of LXC info links to the doc.

[CloudArtAdmins]

Doesn't LXC stand for Linux Containers? So it is meant for Linux, thus should run well on there.

I realise this may not help much with getting a Docker install going, but at least it can be one form of containerisation for self-hosters.

No worries, here, having some kind of base to work from is usually all I need to convert setup documents to podman/docker.

[bioscopic]

@timconsidine great work! Where will you post the HOW-TO? Do you think it should run smooth for Linux users? Will any commands need to be adapted for those running Linux? or will it be out of the box compatible? Not at all familiar with LXC.

I will post a message here (if that's ok) with a link.

Yes it should be fine with Linux. The VPS is running Ubuntu 20.04 as is the LXC container. I'm quite new to LXC so someone will criticise my inaccurate language but it's kinda like a VM inside your normal linux box, bare metal or VPS. LXC is installed in many distros 'out the box', or it is certainly on Ubuntu 20.04 You can test if you have it already by lxc --version and lxd --version. I will add a couple of LXC info links to the doc.

Great! I have a bear metal server running Ubuntu 20.04 standing by and ready to test!

[bioscopic]

Doesn't LXC stand for Linux Containers? So it is meant for Linux, thus should run well on there.

I realise this may not help much with getting a Docker install going, but at least it can be one form of containerisation for self-hosters.

No worries, here, having some kind of base to work from is usually all I need to convert setup documents to podman/docker.

I want to test this out too once you have it running @CloudArtAdmins

[CloudArtAdmins]

Doesn't LXC stand for Linux Containers? So it is meant for Linux, thus should run well on there.

I realise this may not help much with getting a Docker install going, but at least it can be one form of containerisation for self-hosters.

No worries, here, having some kind of base to work from is usually all I need to convert setup documents to podman/docker.

I want to test this out too once you have it running @CloudArtAdmins

Having someone, who isn't me, to test too is always nice to have. So that would be appreciated, thank you. I'll @ you when I can say it is go-for-testing.

[0perationPrivacy]

Note that notifications and updates to the actual sms work on webhooks. If there's a firewall, you must allow webhooks (inbound) from telnyx and twilio otherwise you wont receive any communications.

Ah. That is probably why nothing inbound yet. I have a Telnyx number which routes inbound to a database via a webhook using n8n. I haven't set up webhooks for this app yet. Will look into that.

But also I cannot send out via the app at the moment. Telnyx API key installed and it finds the number ok. But send dialogue "hangs" presumably waiting for a response from some component.

Yes, the application will wait for the status of the message, whether it failed, succeeded, etc. And if the inbound webhook is not being allowed, it will not know the status. In reality this is 2 way communication (VoIP) unlike regular sms.

[slfhstr]

Yes, the application will wait for the status of the message, whether it failed, succeeded, etc. And if the inbound webhook is not being allowed, it will not know the status. In reality this is 2 way communication (VoIP) unlike regular sms.

All working now, inbound and outbound ! Thanks again @0perationPrivacy I will write up my notes and post a link

[slfhstr]

So if @0perationPrivacy doesn't mind, please see this public repo for my notes on getting the app working in a LXC container. https://github.com/timconsidine/LXC-OperationPrivacy-VOIP

May not be "as good as" a Docker installation. But at least it is a self-hosted installation free of Heroku and mongodb.com

[bioscopic]

So if @0perationPrivacy doesn't mind, please see this public repo for my notes on getting the app working in a LXC container. https://github.com/timconsidine/LXC-OperationPrivacy-VOIP

May not be "as good as" a Docker installation. But at least it is a self-hosted installation free of Heroku and mongodb.com

@timconsidine Thanks for this! Just to clarify you did not go forward with setting up a heroku or mongodb stack using their online resources? I wonder when I get to the step where I have to connect the telnyx API if there will be any issues since its already been deployed/connected to heroku and mongodb? We'll find out soon. Ill report any issues.

[slfhstr]

Just to clarify you did not go forward with setting up a heroku or mongodb stack using their online resources?

No I did not touch heroku or mongodb.com

I wonder when I get to the step where I have to connect the telnyx API if there will be any issues since its already been deployed/connected to heroku and mongodb? We'll find out soon. Ill report any issues.

I'm not sure, but I think you can just change the message profile webhook in Telnyx. The app doesn't know about prior Telnyx config and Telnyx just needs to know where to send it from now. I have changed Telnyx webhook value without a problem previously.

[0perationPrivacy]

@timconsidine You do NOT need to create a messaging profile in Telnyx (or Twilio). The app creates it for you when you put in the API key and hit save. That's what the code is doing in the backend, doing all config for you and pulling the number in the dropdown. Should save you a few steps.

[bioscopic]

@timconsidine Im going to have to read up on LXD. Just ran the first command in the new bare metal server and see the following: lxc launch ubuntu:20.04 If this is your first time running LXD on this machine, you should also run: lxd init Creating the instance Error: Failed instance creation: No storage pool found. Please create a new storage pool Did you set your LXD instance up with clustering? Would you like to use LXD clustering? (yes/no) [default=no]:

[slfhstr]

You do NOT need to create a messaging profile in Telnyx (or Twilio).

That's brilliant ... but how does Telnyx know what webhook to use ?
Or you're saying that it is set up by the app ? Awesome !! I will update my document.

If I have set up the messge profile, does it break the app ? Or otherwise not advised ? Seems to be working ! 🤞

[slfhstr]

Just ran the first command in the new bare metal server and see the following: lxc launch ubuntu:20.04 If this is your first time running LXD on this machine, you should also run: lxd init

Darn. I forgot about that. Although LXC and LXD are installed already, you do need to do lxd init I mostly took all the defaults but I followed a guide. Will try to find it. Give me a mo.

[0perationPrivacy]

@timconsidine The app sends a request to Telnyx to add the webhook using the BASE_URL variable.

If you've already added one, the app will override it when you hit save and actually create a new messaging profile. At that point you will have multiple profiles, it won't break it, but you should delete the ones not used to avoid confusion and only keep one messaging profile in Telnyx/Twilio per number.

[bioscopic]

@timconsidine Ive continued down the prompts with LXD. Hopefully this will be helpful to others trying this... let me know if any of the peramiters I selected should be changed? Would you like to use LXD clustering? (yes/no) [default=no]: no Do you want to configure a new storage pool? (yes/no) [default=yes]: yes Name of the new storage pool [default=default]: voip Name of the storage backend to use (btrfs, dir, lvm, zfs, ceph) [default=zfs]: zfs Create a new ZFS pool? (yes/no) [default=yes]: yes Would you like to use an existing empty block device (e.g. a disk or partition)? (yes/no) [default=no]: no Size in GB of the new loop device (1GB minimum) [default=30GB]: 30GB Would you like to connect to a MAAS server? (yes/no) [default=no]: no Would you like to create a new local network bridge? (yes/no) [default=yes]: yes What should the new bridge be called? [default=lxdbr0]: lxdbr0 What IPv4 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: auto What IPv6 address should be used? (CIDR subnet notation, “auto” or “none”) [default=auto]: none Would you like the LXD server to be available over the network? (yes/no) [default=no]: no Would you like stale cached images to be updated automatically? (yes/no) [default=yes] yes Would you like a YAML "lxd init" preseed to be printed? (yes/no) [default=no]:

[slfhstr]

Im going to have to read up on LXD.

I read a few guides, but pretty sure I followed this one : https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-lxd-on-ubuntu-20-04

[slfhstr]

Ive continued down the prompts with LXD. Hopefully this will be helpful to others trying this... let me know if any of the peramiters I selected should be changed

Looks ok to me. I think I left the storage pool as default but I don't think naming affects anything. I just remembered that I set a much bigger storage pool size [200Gb] but only because I have spare space on that VPS and I plan to run a lot more LXC containers. I think [30gb] should be fine for this app.

[bioscopic]

@timconsidine Excellent got through the first step of preparing the LXC container without any issues. Question: After the last step: apt autoremove -y : tidy up Does one log out of the LXC container? Then move to install the mongodb on the server or within the LXC container just created still operating as root after the update?

[slfhstr]

Excellent got through the first step of preparing the LXC container without any issues.

Cool.

Question: After the last step: apt autoremove -y : tidy up Did you log out of the LXC container? Then moved to install the mongodb on the server or within the LXC container just created as root?

1. I did not exit the container. No harm in doing so .. but you then have to go back in.
2. I installed mongodb INSIDE the container. I guess this is inefficient if you plan to use the mongo db deployment for other things. But having it inside the container makes it a lot easier for accessing it from the app. But I guess if you prefer it outside the container, on the VPS or in another container by itself, that should be possible. Just need to amend the .env file so the app can find it. It will be on a different IP which you can find from lxc list if you installed it in its own container.

[bioscopic]

Excellent got through the first step of preparing the LXC container without any issues.

Cool.

Question: After the last step: apt autoremove -y : tidy up Did you log out of the LXC container? Then moved to install the mongodb on the server or within the LXC container just created as root?

1. I did not exit the container.  No harm in doing so ..  but you then have to go back in.

2. I installed mongob INSIDE the container.  I guess this is inefficient if you plan to use the mongo db deployment for other things.  But having it inside the container makes it a lot easier for accessing it from the app.  But I guess if you prefer it outside the container, on the VPS or in another container by itself, that should be possible.  Just need to amend the `.env` file so the app can find it.  It will be on a different IP which you can find from `lxc list` if you installed it in its own container.

Thanks! Just wanted to clarify. I will also install it INSIDE the container.