renewed attempt at dockerization

[dylanwh]

TODO:

• lots of stuff

To test, you can:

• run Makefile.PL
• docker build . -t bugzilla
• docker run --rm -e BZ_db_host=DATABASE -e BZ_urlbase=http://localhost:3000/ -e BZ_db_pass=bugs -ti bugzilla checksetup
• docker run --rm -e BZ_db_host=DATABASE -e BZ_urlbase=http://localhost:3000/ -e BZ_db_pass=bugs -ti bugzilla daemon -- this one should result in a running server.

[melezhik]

@dylanwh i am curious why need to “ run Makefile.PL” ? Usually all compilation happens insider docker build, right ?

[melezhik]

What is a necessity of “BZ_urlbase”, if this is a bugzilla api URL , usually there is docker port mapping mechanism that would allow map docker tcp ports to the host ones, so would it not be enough just specify a port and then map it during docker run ?

[dylanwh]

@dylanwh i am curious why need to “ run Makefile.PL” ? Usually all compilation happens insider docker build, right ?

Side effect of two constraints:

1. Extensions can change dependencies
2. I want an efficient docker build that takes advantage of layer caching

So doing this requires generating the dockerfile. I intend on commiting the "default" configuration dockerfile to the repository, so nobody that it works normally for most people

[dylanwh]

What is a necessity of “BZ_urlbase”, if this is a bugzilla api URL , usually there is docker port mapping mechanism that would allow map docker tcp ports to the host ones, so would it not be enough just specify a port and then map it during docker run ?

Two reasons really.

Bugzilla has numerous protections from being improperly proxied to, and it uses the urlbase understand what requests are valid and which ones to reject. Some of this is implemented in the so-called Hostage middleware, and other parts exist in other parts of the code.

The second reason is that it needs to know how to fully qualify urls in emails and other places outside of a web request context.

I'd like to make this part of the onboarding/setup easier though.