Skip to content
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

extends PR26 to address issues with web root #27

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Paraphraser
Copy link
Contributor

docker-entrypoint.sh altered:

  1. The www folder in the base image is used to non-destructively populate the www folder in the persistent store.

    templates is a sub-folder of www so it is included in the copy.

  2. The following additional argument is passed to domoticz when it is launched by docker-entrypoint.sh:

    -wwwroot /opt/domoticz/userdata/www
    

    This causes domoticz to use the copy of the www folder in
    the persistent store.

  3. More consistent use of environment variables rather than duplicated path names.

`docker-entrypoint.sh` altered:

1. The `www` folder in the base image is used to non-destructively
   populate the `www` folder in the persistent store.

   `templates` is a sub-folder of `www` so it is included in the copy.

2. The following additional argument is passed to `domoticz` when it
   is launched by `docker-entrypoint.sh`:

	```
	-wwwroot /opt/domoticz/userdata/www
	```

	This causes `domoticz` to use the copy of the `www` folder in
	the persistent store.

3. More consistent use of environment variables rather than duplicated
   path names.

Signed-off-by: Phill Kelley <34226495+Paraphraser@users.noreply.github.com>
@Paraphraser
Copy link
Contributor Author

Screenshot 2024-06-09 at 10 33 03

Shows:

  1. domoticz process being passed -wwwroot argument.
  2. Responding properly to curl (IOTstack service definition for domoticz maps external port 8083 to internal port 8080).
Screenshot 2024-06-09 at 10 33 32

Shows browser connecting successfully.

It occurred to me that, although bulk-copying the entire `www` folder
to the persistent store "worked", it was probably storing up trouble
for the future. In particular, if changes were made "upstream", those
would not get copied to the persistent store, unless the copy was made
unconditional, and then it would be difficult to test all the likely
combinations that might be found in user environments.

I think this represents a better approach. It also has the advantage of
making the container's implementation conform with the Domoticz
documentation "as written":

* See [Custom menu](https://www.domoticz.com/wiki/Custom_menu).

1. Original (single) `volumes` clause:

	``` yaml
	- ./volumes/domoticz:/opt/domoticz/userdata
	```

	becomes a (dual) `volumes` clause:

	``` yaml
	- ./volumes/domoticz/userdata:/opt/domoticz/userdata
	- ./volumes/domoticz/templates:/opt/domoticz/www/templates
	```

	Note the insertion of the `userdata` folder on the left hand side
	of the first mapping. This avoids overlapping paths into the
	persistent store, which can cause its own problems.

1. Formally define the second exposed volume:

	```
	VOLUME /opt/domoticz/www/templates
	```

2. Make a copy of the content of the `templates` folder so it forms
   part of the image. The destination path (inside the image) is:

	```
	/opt/domoticz/www-templates
	```

	Any changes to the source `templates` folder which come down
	from "upstream" will always get copied into this folder whenever
	the image is rebuilt.

1. Return the `WEBROOT` variable to its original location at:

	```
	/opt/domoticz/www
	```

2. Withdraw the `-wwwroot` argument (which implies `/opt/domoticz/www`
   as the default).

3. Remove copy of entire `www` folder to persistent store.

4. Add *unconditional* copy of `/opt/domoticz/www-templates` to
   `/opt/domoticz/www/templates`.

   There are two mutually-exclusive options:

	* a *conditional* copy allows users to modify the `.example` files
	  and have their changes persist - at the price of upstream changes
	  never getting propagated; and

	* an *unconditional* copy which guarantees any upstream changes to
	  `.example` files will always get propagated - at the price of
	  losing any user edits to the `.example` files,

	At this stage, the *unconditional* copy seemed appropriate.

Taken together, it works like this:

1. Each time the image is built, a copy is made of the web templates.

2. When the container starts, the external/internal `mkdir` and the `mount` operations triggered by the second `volumes:` clause cause `www/templates` to become a "mount point", thereby making its original contents invisible, both inside and outside of the container.

3. When `docker-entrypoint.sh` runs, it copies the saved copy of the templates back into the mount point, meaning the templates are now available both inside and outside the container. The copy does not affect anything the user does within the templates folder in the persistent store (eg creating `.html` files).

Signed-off-by: Phill Kelley <34226495+Paraphraser@users.noreply.github.com>
@Paraphraser
Copy link
Contributor Author

Further to the latest commit, given:

$ tree ./volumes/domoticz/templates/
./volumes/domoticz/templates/
├── angular.example
├── custom.example
├── custom.html
└── readme.txt

where custom.html is a copy of custom.example, plus enabling "custom" in the user menu:

Screenshot

Also, the commit message seems to have lost some titles. The original markdown follows below (should be more readable).


It occurred to me that, although bulk-copying the entire www folder to the persistent store "worked", it was probably storing up trouble for the future. In particular, if changes were made "upstream", those would not get copied to the persistent store, unless the copy was made unconditional, and then it would be difficult to test all the likely combinations that might be found in user environments.

I think this represents a better approach. It also has the advantage of making the container's implementation conform with the Domoticz documentation "as written":

Service definition change

  1. Original (single) volumes clause:

    - ./volumes/domoticz:/opt/domoticz/userdata

    becomes a (dual) volumes clause:

    - ./volumes/domoticz/userdata:/opt/domoticz/userdata
    - ./volumes/domoticz/templates:/opt/domoticz/www/templates

    Note the insertion of the userdata folder on the left hand side of the first mapping. This avoids overlapping paths into the persistent store, which can cause its own problems.

Dockerfile changes

  1. Formally define the second exposed volume:

    VOLUME /opt/domoticz/www/templates
    
  2. Make a copy of the content of the templates folder so it forms part of the image. The destination path (inside the image) is:

    /opt/domoticz/www-templates
    

    Any changes to the source templates folder which come down from "upstream" will always get copied into this folder whenever the image is rebuilt.

docker-entrypoint.sh changes

  1. Return the WEBROOT variable to its original location at:

    /opt/domoticz/www
    
  2. Withdraw the -wwwroot argument (which implies /opt/domoticz/www as the default).

  3. Remove copy of entire www folder to persistent store.

  4. Add unconditional copy of /opt/domoticz/www-templates to /opt/domoticz/www/templates.

    There are two mutually-exclusive options:

    • a conditional copy allows users to modify the .example files and have their changes persist - at the price of upstream changes never getting propagated; and

    • an unconditional copy which guarantees any upstream changes to .example files will always get propagated - at the price of losing any user edits to the .example files,

    At this stage, the unconditional copy seemed appropriate.

Explanation

Taken together, it works like this:

  1. Each time the image is built, a copy is made of the web templates.

  2. When the container starts, the external/internal mkdir and the mount operations triggered by the second volumes: clause cause www/templates to become a "mount point", thereby making its original contents invisible, both inside and outside of the container.

  3. When docker-entrypoint.sh runs, it copies the saved copy of the templates back into the mount point, meaning the templates are now available both inside and outside the container. The copy does not affect anything the user does within the templates folder in the persistent store (eg creating .html files).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant