(98)Address already in use: AH00072: make_sock: could not bind to address [::]:80
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
AH00015: Unable to open logs
Action 'start' failed.
The Apache error log may have more information.
pam_unix(sudo:session): session closed for user root
Control process exited, code=exited status=1
apache2.service: Failed with result 'exit-code'.
Failed to start The Apache HTTP Server.
Yes and no. Let’s take a step back and look at this.
Before, it sounds like you were running a number of web sites with Apache. Apache listened on ports 80 and 443 and then “proxied” (redirected) the requests as “virtual hosts” and so you could run many web sites on the same server all listening on the same ports (80 and 443). This was “LAMP 101”… the way of the virtual hosts.
Now, let’s say you install Discourse in the official OOTB way. OOTB Discourse will try to bind to the same ports and fail because Apache is already using (bound to) those ports. You have choices:
Run Discourse on a unix domain socket and set up Apache to reverse proxy the Discourse app as a virtual host.
Note: I have tested this and it works; but this is not officially (or even unofficially) supported by Discourse.
Move from Apache to nginx and run all your web servers off ngnix and also reverse proxy the Discourse app as a virtual host, using a unix domain socket for the Discourse-docker production app.
Note: This is not officially supported by Discourse either; and most people who run Apache sites will find it a bit of a “bear” to port all their Apache2 mod_rewrite and encoded geo-ip mod stuff to nginx; but it is doable of course especially if your apps are build for both nginx and Apache2 (that is easier, but still not supported officially).
Expose the Discourse docker container on ports other than 80 and 443.
Note: This is not (really) recommended either (but it is supported officially as I recall). However, most people don’t want to reach a web app by typing in port numbers like https://my-great-discourse-app.org:3334, so most people don’t do this in production. Development is another story.
My “without knowing all your details” recommendation, as someone who has a lot of LAMP and now more and more Discourse, is to run them on separate servers (this is officially supported by Discourse); but if you are really tight for money and must run them all on the same server (or just like having one big complicated server), then you will need to learn to set up Apache2 to reverse proxy to a unix domain socket to / from the Discourse app.
I have tested this, and it is possible to set up Apache2 to reverse proxy to Discourse using a unix domain socket; but this solution is not officially supported (at all).
Note: The link to set up Apache2 with HAProxy was a solution I could not easily get to work; so I abandoned it (no need to only use HAProxy, there are “older ways” to do it) However, you may be better off just following this Discourse tutorial
Publishing on non-standard ports is 100% unsupported. I’ve seen a few topics where rather than bind to a socket the site owners have changed ports and use a reverse proxy to map back to 80/443, but if the end result requires :port then it isn’t supportable.