Forum OpenACS Forum Summaries: Re: OpenACS on Docker
did you make any progress? I looked at the docker container frank provided for OpenACS and was ... mildly disappointed by the lack of understanding what a container is and how it is supposed to be run (e.g. one container, one process running in the foreground).
Therefore I started off with building a base naviserver container and removing the (necessary?) postgresql installation after compiling naviserver. From that I was going to connect it using docker-compose to the database and then have a specific container either for OpenACS or ]project-open[ or customer code which connects the two (and does the automatic pull from the git repository). Goal is to eventually utilize Kubernetes with Ingress to have more than one container run the naviserver off the same custom code.
Long story short, as I am still at the start of said journey, any update where you are at?
I was searching in google openacs container just for curiosity and end up with your post.. we are starting to research about devops, ci/cd and docker.. and eventually would like to make some test with openacs .. but I have to said that I like your approach Malte.. Keep us posted.. I am curious jeje..
I will keep you posted on the roadmap we eventually take..
You should be able to get a naviserver image from https://hub.docker.com/repository/docker/sussdorff/naviserver
In case you wonder, here is the OpenACS Dockerfile (I do need to setup gitub to link the hub.docker.com to the Dockerfile... but well...).
As I mainly work with ]project-open[, my current config files are specific to it, but the yist of the idea is:
1) Two Replicas of Naviserver (still have to identify what are the best resource requirements and if I even need two replicas as Naviserver is multithreaded to begin with, on the other hand works nice with rolling updates, oh well...)
2) Put the OpenACS / ]project-open[ code into the Naviserver dockerfile and then "release" a naviserver package (e.g. sussdorff/naviserver:openacs. This is what the OpenACS dockerfile currently does.)
3) Run the database on a specific node which is a little bit beefier than the naviserver ones. Eventually I can go into postgres primary .... but why make live hard now.
I am already at the point where "docker-compose up" nicely starts up OpenACS and will deploy to my docker swarm soon.
Let me know if you are interested in any of this.
I just saw this thread today. The goal of this docker container was to provide an easy one-step installer for relative noobs, and I think it serves it's purpose. It's just a kind of lightweight VM.
I guess what Malte wants is a scalable installation.
I'm sympathetic with that thought, but I understand that scaling OpenACS/]project-open[ instances really depends on the database rather than the NaviServer CPU load.
But to my knowledge databases don't scale on massive parallel shared nothing architectures without sacrificing consistency.
So my though is be move towards AWS or Google Cloud with their managed PostgreSQL services. I believe Brian showed me some impressive performance figures. Then just use Kubernetes or similar to spawn a few NaviServers behind an IP based load balancer. That shouldn't be too difficult...
OpenACS really depends on the database rather than the NaviServer CPU load.it really depends. NaviServer is especially good on scaling over multiple cores, and since the availability of cores increases continuously, this is usually not a bottleneck. If one is running a server where 80k user log-in per day, and one has to serve ~9k concurrent users (as we had in peek-corona times), then the CPU load is substantial.
But to my knowledge databases don't scale on massive parallel shared nothing architectures without sacrificing consistency.This is in general true (especially for massive scalability) and is a consequence of the CAP theorem. There is a constant progress for high availability pg, load balancing (see e.g. ) but this helps mostly for improving availability (as always, it depends on the load pattern: it is much easier to scale with many readers than with many writers). But don't expect e.g. a pgpool-II installation to be any faster for smaller user numbers compared to a configuration where pg and nsd run on the same machine with high bandwidth communication.
For large scale applications we see currently rather bottlenecks with huge content repositories, containing double- and triple-digit TB on files that must be highly available, especially when no shared disk fail-over or block-device replication are available. In case there is interest, i've done some work on integrating MongoDB for such purposes, which scales horizontally.
Concerning the Docker image: from my point of view, it is most useful for quick tryout scenarios and for easy standard deployments. I would not expect it solve scalability issues right now. When using pg e.g. in the AWS cloud, i would not expect it to scale better. When using multiple nsds connecting to the same OpenACS instance, be aware that out-of-the box, there will be no cache consistency. Running multiple e.g. po instances all with one nsd against one pg isntallation (what pg call "cluster"), this will work easily.