Closed teolemon closed 6 years ago
Should also be interesting for automated builds with Bitbucket Pipelines.
We moved to github, so should be easier to find something. Travis build is already kind of up.
OpenFoodFacts resources :
Some Docker resources:
Unfortunately, that's just one step. Stitching together Config.pm, Config2.pm, Apache2 site, nginx site, etc. dynamically (based on a wildcard domain … supplied by whom?) sounds quite fragile. I'll admit that I have no experience with Docker, so it might be easier than I think. 😄
I have a somewhat runnable version of Product Opener on Docker in the 306 branch with a simple README. Is this about what you had in mind @teolemon @nicolasleger?
@hangy please share it with us, I was trying a lot to have a proper local env working via Docker.
@nicolasleger Thanks for the hint. I like that approach as well. Right now, I'm thinking we should just add all variants to the official repo and have them available as options. For the time being, I don't see any other use than using them for local development (which is really useful 👍), so that should be fine.
I saw that you have https://github.com/nicolasleger/openfoodfacts-server/blob/ae78aab9b62566caebb302595f834c401f06c744/Dockerfile#L66 as an open TODO. With the changes of 302347d890ad6ea8802b1145223fd4dab7ecf55b, you could remove MongoDB from the app
container.
In your example, I noticed that Docker compose can also build images (how could I miss that? 😆), so I think I'll adjust my Dockerfile accordingly.
Thanks ! Yes it is better to split services in Docker compose if config between them can be dynamic. Via environment variables or default local for Mongo for example. See The Twelve Factors principles https://12factor.net/ for inspiration.
That's basically what I tried in https://github.com/openfoodfacts/openfoodfacts-server/compare/issue/306-docker?expand=1 - also as a proof of concept that ProductOpener still works with nginx and apache on different machines, as long as some volumes are shared. :wink:
@nicolasleger