So, building on #407 which is now closed, I've been figuring out a neater way to start an Apache2 server for development, and here's how I'm doing it so far...
Firstly, I create a new apache.conf file and save it somewhere accessible inside /workspace. It could even be committed to the git repo. Something like this:
````
PidFile /workspace/apache.pid
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5
User www-data
Group www-data
HostnameLookups Off
ErrorLog /workspace/error.log
TransferLog /workspace/transfer.log
LogLevel info
IncludeOptional /etc/apache2/mods-enabled/.load
IncludeOptional /etc/apache2/mods-enabled/.conf
Listen 8080
DocumentRoot "/workspace/[PROJECT NAME]"
Options +Indexes
Options FollowSymLinks
AllowOverride all
Require all granted
AccessFileName .htaccess
Require all denied
````
And I start the server with this custom conf file by using the following command (as documented here: (https://www.techrepublic.com/blog/linux-and-open-source/control-apache-with-the-apachectl-command/):
apachectl -f /workspace/[PATH TO MY CONF FILE]/apache.conf
I can grab the PID at /workspace/apache.pid, and I can kill the service with kill [PID].
I've still got to figure out a bunch of stuff around what I can and can't do with this custom conf file, but it's a start.
Can anyone from GitPod (@meysholdt @svenefftinge @jankeromnes @akosyakov @32leaves) improve on this, or suggest a supported way of starting an Apache server?
Potential paying customer here, if I can nail this. :o)
hey @contention,
sure, I'll look into it. I think the example from the issue you pointed to is not bad. It can be tried by clicking on this link.
https://gitpod.io/#https://github.com/meysholdt/apache-in-gitpod-example
However, in that example, the Apache process kills itself whenever the Terminal resized. I've getting the feeling Apache is not supposed to run in the foreground. See https://github.com/meysholdt/apache-in-gitpod-example/issues/1
I'll post here when I have more updates.
Hey, yeah, what I'm trying to do is solve the limitations in that example, and create a MUCH simpler way to run Apache... so without having to side-load it via a Dockerfile, and in a more standard configuration - ie, so it's running as a standard process and not in the foreground :o)
Not easy when you don't have root access... but this way seems to work pretty well so far. And we can still log/view errors etc in the /workspace dir.
Look forward to any updates.
Thanks.
hey @contention,
I've simplified the example a lot and changed it to run Apache as background process, so it no longer crashes when the terminal is resized.
I've moved the example to a new location:
https://github.com/gitpod-io/apache-example
let me know what you think.
cheers,
Moritz
Hey @meysholdt,
I simplified your example, it now only has two files ".gitpod.yml" and ".gitpod.dockerfile".
Nice.
So what's the benefit of reinstalling Apache via a Dockerfile over running the already installed Apache with a custom conf?
Like this (also only requires 2 files - .gitpod.yml and .gitpod.apache.conf):
https://github.com/contention/gitpod-apache2
Anyone know? I'm genuinely curious, because this way seems a lot simpler!
interesting question. I did put the apache.conf into /workspace because I thought when you run an Apache web server you also want to see and maybe change its config. Therefore, I tried to treat the Apache config like source code.
What's your opinion on this? :) Would you want to edit the config or would you want to not see it and just have apache serve one folder from your workspace?
Likewise - I'm committing a project specific .gitpod.apache.conf into the project root so it can be edited easily, however it's not something that I think will need to be edited often.
I'm just wondering if there are any reasons NOT to spin up an Apache process with a custom conf (using that -f flag), from the version of Apache that's already installed on the base image.
Seems to work ok so far though, and it means we can use the base Docker image as it is which keeps it simple... at least in my mind. :o)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.