[Noob Question] Location of WEBUI repo and editing

[Corshi]

Last auto's repo has a bug that adds empty layers into the models after merging. I would like to open the directory of auto's webui and just drop the old files, or even the modded files made by community. Problem is, I don't know how this works. From what I understand, Docker is a mixture of virtualization with command-line hub and symbolic links. Those files are stored somewhere. In virtual drive, in .zip or just in some location, as loose files.

So just where are those files?

And if you answer, please add this to your FAQ, under "Docker Noob Questions".

Thanks ✌

[Corshi]

This also can be transferred into suggestion. If files are stored in secured visualized environment controlled by Docker, it would be nice to have an "Overwrite" folder in your repo.

So like "overwrite-auto" folder, to overwrite files of auto's repo - if the file's names and locations are set correctly to the og (downloaded) repo.

[AbdBarho]

I would like to open the directory of auto's webui and just drop the old files

Unfortunately, that is not possible.

Those files are stored somewhere. In virtual drive, in .zip or just in some location, as loose files.

Yes, they are stored somewhere, but not in any of the options that you mentioned, each layer of the docker image has its diff saved in binary format. You cannot just browse through the image or modify it.

That being said, you can modify the container, you can either copy your files while building using the COPY command You can also mount your files and access them from the container. Or you can run the container and copy files to it in runtime using docker cp

All of these can be used to achieve the override you mentioned.

That being said, what you are requesting goes against the core principles of docker. If you want the flexibility to do what ever you want, I highly recommend that you install from the original repo from scratch, docker will only stand in the way.

please add this to your FAQ, under "Docker Noob Questions".

An introduction to docker is out of scope for this repo, there are many good online resources for that. https://www.youtube.com/watch?v=fqMOX6JJhGo

[Corshi]

Thank you, you gave me a lot of useful pointers. I really do appreciate it.

[DevilaN]

Overwriting files by scripts is tricky-sneaky. Eventually you end up with state you are not sure how works.

You might want to tag images with versions (would be better if @AbdBarho done it with semantic versioning) using docker-compose.override.yml with entry naming image, like:

service:
  auto:
    image: webui-docker-auto:1.2.3-COMMIT_HASH

Also you can tag current image with other name for later purposes like: docker image tag webui-docker-auto:latest webui-docker-auto:31e4dec0 Most of the time base image layers does not change and there are only changes with python code, so multiple images have most of layers common and does not take up much more disk space. You can always use docker image ls to show what images you've got, and then git checkout for specific commit + correction in override file to use named image with this very commit.

That is poor mans backup unless there is a support for tagged version of repo + images used here.

Also you can add another layer to existing images. If you want, you can docker exec into running container and make proper changes. Also you can copy files from / to container with command: docker cp <containerId>:/file/path/within/container /host/path/target. Where <containerId> is a hash-like string from docker ps command. If you are happy with changes you can even make this permanent with docker commit <containerId> making image from this very container with <containerId> id-string. Then there is only a matter of docker image ls and naming it with docker image tag + changing image: section in override file so selected service uses your image.

Best regards

[AbdBarho]

@DevilaN I am not sure how to semantically version a container?

Maybe I could adopt the versioning scheme of the original repo, but there is none to speak of. Do you have any suggestions?

[DevilaN]

@AbdBarho Any versioning scheme would be better than nothing. If there is any unique tag (even sequential numbers) on image that allows to do git checkout on specific commit in this repo, than you can always switch back to previous state of entire app without a need to recompile it from scratch. This will also give benefit of automatically build images when needed. If nothing changes new version will build lighting fast from build cache when running it first time after git pull on this repository. If anything changes, new version will build automatically and there is no need to instruct people that "you should start with --build flag this time or there will be some issues".

[AbdBarho]

@DevilaN I started with a sequential scheme in #164, lets see how it evolves

[github-actions[bot]]

This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity.