WSL2 & Docker-compose

Ignition
1

I am working with one of my engineers on trying to resolve an issue with VSCode, WSL & Docker fighting each other and I am not sure if my issue at this point is related to the docker image file permissions, vscode or linux, but hopefully @kcollins1 you might can help this will solve the issue for others in the future here.

They are running a compose network in WSL, and interacting with it through VSCode for direct file manipulation and source control management. However we are having issues where the WSL file permissions on the generated content are all switched to the ignition GID:UID and VSCode isn’t able to save anything, without resetting the ownership on each new file created. As well all version control doesn’t work without changing ownership, because git can’t create its necessary files without constantly sudoing

We tried setting the GID:UID to 1000 (to match the user) but that didnt seem to solve it, and we are not exactly sure on how to allow for the direct file interaction while not screwing up the container permissions.

This is our docker-compose, using the bind mount so that we can achieve direct file access in the local directory:

version: "3.8"
services:
  ignition:
    image: kcollins/ignition
    ports:
      - "4000:8088"
    volumes:
      - "./template_backup.gwbk:/restore.gwbk"
      - ignition_data:/var/lib/ignition/data
    environment:
      GATEWAY_ADMIN_PASSWORD: password
      IGNITION_UID: 1000
      IGNITION_GID: 1000
volumes:
  ignition_data:
    driver: local
    driver_opts:
      type: none
      device: "./ignition_data"
      o: bind

The end goal here is the ability to run multiple gateways in a network, with the data directories all mounted into sibling folders, to manage the entire architecture.

Note: This practice has frequently had me shaking my fist at the sky and wishing this developer was also on MacOS/Linux instead of windows

2

Good day! :wave: First off, I see your use of IGNITION_UID and IGNITION_GID in the environment. These are were only available as build arguments when creating the image. By adjusting these with a docker build --build-arg IGNITION_UID=1000 --build-arg IGNITION_GID=1000 ... against kcollins/ignition, you could create your own image where ignition user would be a custom UID/GID.

With kcollins/ignition:8.1.9 (see PR #75 for details), the container now starts as root and the entrypoint takes care of synchronizing filesystem permissions (while root) before stepping down to ignition user for the actual running of the container. This is a typical practice in most modern container images nowadays, via the gosu (there are also other alternatives) utility.

So, the good news is that if you change your image tag up there to image: kcollins/ignition:8.1.9, those environment variables will now actually take effect! :sunglasses: You’ll see some informational output in the logs that lets you know that filesystem permissions are being adjusted–this step can take a little bit of time, but is only required the first time you start a new container.

Let me know if you have any further questions or issues!

1 Like
3

By any chance do you know the timeline for these to be added to the inductiveautomation/ignition image? On a Mac my life is easy and MacOS creates all files under <username>:staff, same with docker on windows <username>:<username>

However when you go to do this on linux, it decides to make everything root:root, and so we are forced to use your kcollins/ignition image and provide 1000:1000 for the UID and GID. Without doing that, it makes version control really difficult in mounted volumes, because either you sudo every command you run, or you get permission denied errors all over the place.

4

We’ve had this in the backlog for a while. In the meantime, I’ve successfully implemented a good solution in kcollins/ignition as you mention. I’ve went ahead and updated the ticket here on our side with some of the updated thinking on this–hopefully we can get to it sooner vs later. It will likely be opt-in for inductiveautomation/ignition:8.1.x (i.e. if you don’t specify anything, it will continue to run as-root like today).

1 Like
5

Saw this on another forum post and thought, hmm why does that sound ironically familiar? :joy::joy:

6

The good news is that the addition of IGNITION_UID and IGNITION_GID environment variables in inductiveautomation/ignition image just got merged today and should be in the nightly tag tomorrow! It pretty much works the same as kcollins/ignition image.

EDIT: Thankfully, the bug in that post regarding -1 * 100 ending up being reported for the process CPU load doesn’t seem to manifest when using a standard user account on Linux.

1 Like
7

Woohoo!

Question, will this back port to versions older than 8.1.17 containers? so that the developers who are stuck on something like 8.1.15 gateways for a while can use this feature as its version agnostic?

Separately, a more linux question, when re-creating a container with this, prior to rebuilding the container should all files in the data folder (or wherever a bind mounted volume may be) be modified for use by the desired group? Currently the rough solution I have been using is a chmod -R a+rwX directory/path on the folder being used. In this case we would either want to set the GID to 1000 so it acts as the user, or put the user and the gateway in a common group and perform chgrp -R group_name directory/path?

8

We won't be back-porting this and rebuilding+pushing older Ignition versions back up to Docker Hub, no. However, once this gets to release, I'd be happy to put together a derived image that can be built against one of those older upstream images to shim in this functionality. It will look very similar to what is mentioned here.

With this new configuration, the entrypoint script still runs as root and will automatically chown -R (for the most part, there is some advanced handling built into there for symlinks, too) files under IGNITION_INSTALL_LOCATION (including under any bind-mounts or volumes in the tree) to the target UID:GID specified. It will not modify permissions, just ownership.

1 Like