The entrypoint.sh overrides any customization or nginx configuration that is made on stop/start

[svscorp]

adop-nginx/resources/scripts/entrypoint.sh

Lines 4 to 5 in 8fec90c

	cp -R /resources/configuration/* /etc/nginx/
	mkdir -p /usr/share/nginx/html/ && cp -R /resources/release_note/* /usr/share/nginx/html/

[nickdgriffin]

I'm not really sure why this is an issue. It is specifically designed to do this so that regardless of whether a volume is used or not the correct configuration is put in place - eventually it might be tokenised.

If customisation is required then I suggest either overriding the main file in the container, or baking your own image that includes whatever configuration you desire.

[svscorp]

Hi @nickdgriffin,

Thanks for reacting quick on this.

It's kind of a concept issue IMHO. Usually everything that is immutable is placed in the container itself, while state/data is placed outside. It is not expected, we expose release notes to the volume - so it's expected you can change it (otherwise, what's the reason to expose the volume?). If consistency is the key - the volume should be removed to not confuse a user (because in other containers you can change data in the volume)

About the second point, it's of course possible to bake your own image and customize it in a way you want, but it's a forcing customization action. Why should I create a new image, think about having a registry to put that image (or build it locally) if it is possible logically just to change the static content.

Also, overriding main file - can be the case, but do it just to fix configuration or add an extra route it's kind-a excessive.

Is this a good reasoning/thinking about?

[nickdgriffin]

The reason the configuration and release note are in the volume is because they can reference stuff that isn't baked in - the Nginx config has an "include" and the release note reads a "bp" folder.

For the Nginx configuration I'd like to restructure it one day to have more "include" statements that provide more flexibility to add locations under the main domain or to add additional domains, but it still mean that the main files from the image are copied into the volume on start by the entrypoint.

[mlushpenko]

@nickdgriffin I realize it is made for easy deployments of ADOP, but it breaks normal way of working with containers: as @svscorp mentioned already - core installation is part of Dockerfile, everything else is added via environment variables and volumes. I was working on https support for nginx and hit the same problem - my config was overridden. Then I made a template as you did with nginx.conf and it works now, but it's ugly.

And in general this way of setting things up adds to one of core adop design problems in my opinion - everything is too tightly integrated and it's quite hard to change something. I wanted to add ldaps support for all containers to integrate ADOP with enterprise ldap and it's quite hard even to run a single ADOP container standalone, because it wasn't designed for that.

[nickdgriffin]

@mlushpenko I consider it quite normal to extend a container with your own customisation - ultimately we'd like the Nginx configuration to be more flexible but there will always be an element of something being within the image that someone will want to override at some point. Forking the repository and having it build in Docker Hub with your own customisations doesn't require too much work I don't think.

I agree there is work to do to decouple some of the components but like you said it wasn't designed for that (initially) - that doesn't mean there isn't room for improvement. There will always be an aspect of coupling though seeing as that is the point of the platform - to provide an integrated set of tools.

[mlushpenko]

@nickdgriffin sure, we just want to contribute back to make the platform more robust. As part of this initiative, I created a pull request and was hoping somebody could review it, so the work doesn't end up just in my dockerhub, but becomes part of the core platform
#41

[svscorp]

@nickdgriffin

"release note reads a bp folder" - that doesn't help it just adds below area for links... but when I want to customize a css I have to create our own image. My concern is that why are we forcing someone who just want to put a small customization on the main page to create image -> that also forces to have a Docker registry (private).

To not create too much discussion I want to understand, can we change this or this topic should be closed as it won't change? I can do what is required and PR that.

What's about exposing one more volume with "/resources" folder to be able to overwrite/customize what is coming up with every container run? Or what's about adding an include of "custom.css" next to the main css file to be able at least to change colors.

Or, what's about adding a flag into entrypont.sh that will accept a variable to either overwrite or persist the volume?

I am looking about any opportunity to have flexibility. Rebuilding image every time I doing change to static content - it's not cool. I understand it needs to be done if we would have a web application in the container - it is a deliverable.

[nickdgriffin]

I'm open to it changing as long as the "out of the box" configuration and release note are immutable inside the image - they can be changed though to be more supportive of custom configuration, but when the container is restarted I expect the copy in the volume to be replaced with the image version. If there was an option to totally override the config location or "switch off" the copy then that'd be fine too, but the default behaviour should be how it is now.

In the future the config might be either dynamically generated or templated in some form, neither of which will allow customisations unless "handles" are put into the config (like expecting config in certain places, or certain file names being allowed).

If someone wants to change the "core" parts of the image they should create their own image - it doesn't require a private registry unless the changes cannot be open sourced, as hub.docker.io can be used to build and publish the image from the forked repository.

[svscorp]

@nickdgriffin

Can we restart the discussion on this topic? In short, I suggest to copy both configuration and html to their folders once in Dockerfile. Then with 2 ENV variables CUSTOM_CONFIG and CUSTOM_HTML that are false by default control the behavior.

Everyone is happy. On one side by default (in adop-docker-compose) this variables won't be given, so data persistence will be enforced on every container start. If someone want's to customize - there will be an easy way to do that, without going for new image creation + at least whole entrypoint.sh will be copied for 2 lines change.

Let me build and PR that.

[nickdgriffin]

Yeah that approach sounds sensible to me.

[svscorp]

It is also a way to do that in #36 but not sure it's better.