Derived Image Creating Temp Admin User

Ignition
,
1

I am running into an issue with my derived container image. After I create the image I am passing in the Gateway admin username and password as ENV variables. When I first boot the container I can login and the temp identity provider does not get created. When I take the container down and spin it back up, a temp identity provider is created a long with a temp Admin user. I don’t understand why that is happening. I followed the derived ignition example from github and for my case I removed a lot of the extra stuff. I am just trying to make a simple derived container with third party modules copied in. When the image isn’t derived the temp admin user and provider does not get created.

Here is my Dockerfile:

ARG IGNITION_VERSION=8.3.1
FROM inductiveautomation/ignition:${IGNITION_VERSION} AS prep

USER root

# Set working directory for this prep image and ensure that exits from sub-shells bubble up and report an error
WORKDIR /root

# Use bash strict mode for all following RUN steps in this stage:
# -e: fail on first error, -u: fail on unset vars, -o pipefail: fail if any piped command fails,
# -O inherit_errexit: preserve -e behavior in subshell/command substitution contexts.
SHELL [ "/usr/bin/env", "-S", "bash", "-euo", "pipefail", "-O", "inherit_errexit", "-c" ]

COPY modules/*.modl /root/

# Final Image
FROM inductiveautomation/ignition:${IGNITION_VERSION} AS final

# Temporarily become root for system-level updates (required for 8.1.26+)
USER root

# Embed modules and base gwbk from prep image as well as entrypoint shim
COPY --from=prep --chown=ignition:ignition /root/*.modl ${IGNITION_INSTALL_LOCATION}/user-lib/modules/

# Return to ignition user
USER ignition

# Supplement other default environment variables
ENV ACCEPT_IGNITION_EULA=Y \
    IGNITION_EDITION=standard \
    GATEWAY_MODULES_ENABLED=all \
    DISABLE_QUICKSTART=true

Here is the docker-compose that uses the image:

services:
  backend-gateway:
    image: myimage/coolgw:1.0.0
    container_name: coolgw
    user: "0:0"
    ports:
      - "${HTTP_PORT:-8088}:8088"
      - "${HTTPS_PORT:-8043}:8043"
    command: ["-n", "tonyhawks-coolgw","-m","2048","--","wrapper.java.initmemory=2048"]
    environment:
      GATEWAY_ADMIN_USERNAME: "admin"
      GATEWAY_ADMIN_PASSWORD: "password"
      ACCEPT_MODULE_LICENSES: "com.cirruslink.mqtt.transmission.gateway,com.cirruslink.mqtt.engine.gateway,project-scan-endpoint"
      ACCEPT_MODULE_CERTS: "com.cirruslink.mqtt.transmission.gateway,com.cirruslink.mqtt.engine.gateway,project-scan-endpoint"
    volumes:
      - ignition_data:/usr/local/bin/ignition/data/config
    restart: unless-stopped
volumes:
  ignition_data:
2

Your ignition_data volume mount point should probably be /usr/local/bin/ignition/data.

1 Like
3

In this case I am intentionally pointing it to the config folder because the end goal is to abstract out different folders under the config, so I can track it with git and create different modifications. I was running into the same issue using a bind mount and for this version I was working on I decided to use a normal docker volume to test if the same problem was occurring.

4

Independently of whether you have additional deeper mounts, you should still have a [named] volume at the root /usr/local/bin/ignition/data location.

1 Like
5

@kcollins Could you please explain why?

6

There are pieces of state, such as projects, what might be under data/var as well as other files such as commissioning.json, modules.json, and others. There are additional insights on data/var and other folders here in the docs.

Various systems (including third-party modules) are going to expect continuity across restarts of a given gateway via a persisted volume against /usr/local/bin/ignition/data.

2 Likes