-
Notifications
You must be signed in to change notification settings - Fork 390
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Development Docker Setup #1206
Development Docker Setup #1206
Conversation
Thanks! I know @jpatokal was looking to do something like this... I'm not sure offhand how many things are hardcoded |
Having spent a bit more time with this setup, I've already found a couple of Still, I think even in it's current form it's already useful as most of the functionality is available. As a side note, I've been using another container with PHP 8 (because the INSTALL notes mention that it's not compatible) installed to manually test side-by-side. I actually haven't found any breakage on that front (though there are quite a few warnings). |
I've been fixing code up that I "knew" should be problematic on PHP 8... If you've got warnings, feel free to dump them on another issue and I'll take a look. A lot of them should relatively easily resolved. |
FWIW, I would merge this without it being "perfect"; I would want to at least quickly test it first though ;) |
This came up as part of my [Docker setup testing](jpatokal#1206 (comment)) where I don't have `https` set up. I think it makes sense to follow whichever origin (protocol, host, and port) was used to reach the page in the first place. The code already uses `location.host` and gets the port instead of hardcoding 443. The real `nginx` file redirects all requests to HTTPS so this change does not affect any real traffic. When testing with my `http` setup this fixes: - flight list export buttons (CSV and KML) - settings page backup button - sign-up page new profile URL (display only, it's not a link since the profile doesn't exist yet) I haven't been able to reproduce the `case 2:` behavior from the [login function](https://github.com/jpatokal/openflights/blob/master/openflights.js#L2962). I believe this is meant to reset the language from whatever was set prior to login to the user's settings-defined language. Still, it does not work the way I described it above on `openflights.org` either.
This came up as part of my [Docker setup testing](jpatokal#1206 (comment)) where I don't have `https` set up. I think it makes sense to follow whichever origin (protocol, host, and port) was used to reach the page in the first place. The code already uses `location.host` and gets the port instead of hardcoding 443. MDN shows this feature is widely supported by browsers: https://developer.mozilla.org/en-US/docs/Web/API/Location/origin The real `nginx` file redirects all requests to HTTPS so this change does not affect any real traffic. When testing with my `http` setup this fixes: - flight list export buttons (CSV and KML) - settings page backup button - sign-up page new profile URL (display only, it's not a link since the profile doesn't exist yet) I haven't been able to reproduce the `case 2:` behavior from the [login function](https://github.com/jpatokal/openflights/blob/master/openflights.js#L2962). I believe this is meant to reset the language from whatever was set prior to login to the user's settings-defined language. Still, it does not work the way I described it above on `openflights.org` either.
This came up as part of my [Docker setup testing](#1206 (comment)) where I don't have `https` set up. I think it makes sense to follow whichever origin (protocol, host, and port) was used to reach the page in the first place. The code already uses `location.host` and gets the port instead of hardcoding 443. MDN shows this feature is widely supported by browsers: https://developer.mozilla.org/en-US/docs/Web/API/Location/origin The real `nginx` file redirects all requests to HTTPS so this change does not affect any real traffic. When testing with my `http` setup this fixes: - flight list export buttons (CSV and KML) - settings page backup button - sign-up page new profile URL (display only, it's not a link since the profile doesn't exist yet) I haven't been able to reproduce the `case 2:` behavior from the [login function](https://github.com/jpatokal/openflights/blob/master/openflights.js#L2962). I believe this is meant to reset the language from whatever was set prior to login to the user's settings-defined language. Still, it does not work the way I described it above on `openflights.org` either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not going to claim to be any sort of Docker expert (to any extent), but it should(TM) be possible to make a common "base" image, and then have the differences between the images (pretty much the PHP install stuff at this point)
https://docs.docker.com/build/building/multi-stage/ as at least one way
I don't know if this is any harder/easier with docker compose too...
It probably doesn't make too much difference as things are relatively simple, and probably aren't be going to get muc more complex in future, but it would reduce some duplication.
1. `cp php/config.sample.php php/config.php` and set `$host = "db";` so the host name matches the | ||
the database container host name. | ||
2. Run `docker-compose up` to create the containers. | ||
3. Install local PHP dependencies inside the container. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason we can't run composer automatically?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We only mount the source code when the container is created. It might be possible as part of CMD
but this wasn't a priority for me. If you have PHP installed locally, you can run it outside of Docker too.
Dockerfile
Outdated
# note that these symlinks require the repo be mounted @ /var/www/openflights | ||
RUN rm /etc/nginx/sites-enabled/default | ||
RUN ln -s /var/www/openflights/nginx/openflights-dev /etc/nginx/sites-available/ | ||
RUN ln -s /var/www/openflights/nginx/openflights-dev /etc/nginx/sites-enabled/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't it more usual to chain the sites-enabled/foo
to symlink to sites-available/foo
, even if that is a symlink itself?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/shrug
We don't even need the sites-available
one.
Wrapping up the PHP8 migration would achieve the same de-duplication. :) |
Dockerfile
Outdated
RUN add-apt-repository ppa:ondrej/php -y | ||
RUN apt-get install -y \ | ||
php7.4 php7.4-curl php7.4-fpm php7.4-gd php7.4-mbstring php7.4-mysql php7.4-xml | ||
RUN mkdir /run/php # For the php-fpm socket file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/var/run/php/
is used in the nginx config below...
And does this actually need doing manually?
Dockerfile-php8
Outdated
# System-level PHP setup | ||
RUN apt-get install -y \ | ||
php8.1 php8.1-curl php8.1-fpm php8.1-gd php8.1-mbstring php8.1-mysql php8.1-xml | ||
RUN mkdir /run/php # For the php-fpm socket file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/var/run/php/
is used in the nginx config below...
And does this actually need doing manually?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't remember the details - I did need it at some point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It appears that /var/run
is a symlink to /run
on Ubuntu.
root@af5f1b02b4f1:/# ls -lah /var/run
lrwxrwxrwx 1 root root 4 Nov 30 2022 /var/run -> /run
Still need to double-check if this needs to be done manually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/var/run/php/
is used in the nginx config below...And does this actually need doing manually?
OK, it's because we run php-fpm
directly instead of going through systemd
...
|
||
location ~ \.php$ { | ||
include snippets/fastcgi-php.conf; | ||
fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't going to work for PHP 8.1 of course
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, forgot I have a local change for this in the PHP8 container.
I could symlink these to an unversioned name or update /etc/php/fpm/pool.d/www.conf
to remove the version from the name.
Also requires Jani having the time ;). Not as time intensive as rebuilding on a new machine, though. Mostly just installing the newer packages, minor change to the default nginx config, update and reboot... But then there'll be later PHP upgrades to do. PHP 8.2 and PHP 8.3 will bring their own pain, almost certainly. |
How about I just remove the PHP8 one for now. It's a later addition which I was using for one of the PRs and definitely not needed in the MVP. |
PHP8 broke a lot of stuff, which is why I fell back on 7, and even that caused significant pain. I'm hesitant to upgrade unless there's a pressing reason to do so. Re: hardcoded https, these are messy leftovers from the days when OpenFlights was upgrading to be 100% HTTPS, but it's been HTTPS-only for years now so explicitly specifying the protocol should be unnecessary. |
FWIW, I've changed my dev install to using PHP 8.2, and while there's a bit of logspam (filing issues as I've seen them), it's mostly working just fine. I think we've fixed up most of the big issues. PHP 7.4 has been EOL since late 2022 as per https://www.php.net/supported-versions.php |
OK, that's good to hear. I do recall 8 upgrading a lot of warnings to errors, so I'm hoping these have been actually fixed at source as opposed to us just having different php.ini settings or something! |
I'm not quite confident to say it's time to upgrade now, but I think it should be in a near term plan |
This automates most of the setup instructions present in the `INSTALL` file by using Docker.
@reedy A couple of small updates if you want to test. Otherwise, I'll merge and we can improve upon this later. |
This tries to automate most of the setup instructions present in the
INSTALL
file by using Docker. I don't know if this is a good way of getting this up and running locally but it worked for me so I wanted to share it.It's a bit janky in places - I know. I'd be happy to improve it if there's any feedback.
If it's not useful, no problem.