@ancient-wolf-19325 i'm setting up a dockerfile and have been using

root

. is

root

strictly necessary or can i create a group and user and direct flyte to use a different directory?

It is not strictly necessary to use

root

in your Dockerfile for Flyte. You can create a custom user and group, set the

WORKDIR

to a directory owned by that user, and configure Flyte to use that directory. Flyte components and tasks can run as non-root users, and the recommended best practice is to avoid running as

root

for security reasons. You can set the working directory in your Dockerfile using the

WORKDIR

directive and switch users with the

USER

directive. For Flyte tasks, ensure your code and dependencies are copied to the directory specified by

WORKDIR

, and that directory is accessible to the non-root user. This approach is supported and commonly used in Flyte deployments, including in official images and Helm charts, which set

runAsUser

and

runAsGroup

in the Kubernetes security context to non-root values such as

1001

or

1000

(d2bf892a, a83a0635, e2ed6d04). When using Flyte's fast registration or custom images, ensure the

WORKDIR

matches where your code is copied, and update the

PYTHONPATH

if needed. If you use a non-default working directory, you may need to set the

destination-dir

during registration or ensure your code is discoverable by Python (e2ed6d04, e2ed6d04). Would you like more detail or a sample Dockerfile? Sources: - d2bf892a - a83a0635 - e2ed6d04 👍 1 button 👎 0 button 💡 Hint: Mention @ancient-wolf-19325 in the thread for followups.

@ancient-wolf-19325 yes, give me a sample Dockerfile that creates a custom image to be used by tasks that uses a non-root user. i'm getting

NoAuthenticationInformation

after moving to a non-root user

It seems likely that you can create a Flyte-compatible Dockerfile using a non-root user by creating the user/group, setting permissions, and ensuring environment variables (like AWS credentials) are accessible to that user. The

NoAuthenticationInformation

error suggests the non-root user may not have access to the credentials or environment variables needed for authentication (e.g., to S3). Here’s a sample Dockerfile pattern based on Flyte community guidance:

FROM python:3.11-slim

# Create a group and user
RUN groupadd -r flyte && useradd -m -r -g flyte flyte

# Set working directory and permissions
WORKDIR /app
RUN chown -R flyte:flyte /app

# Install dependencies
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy your code
COPY . /app
RUN chown -R flyte:flyte /app

# Switch to non-root user
USER flyte

# (Optional) Set environment variables if needed
# ENV AWS_ACCESS_KEY_ID=...
# ENV AWS_SECRET_ACCESS_KEY=...

CMD ["python", "your_entrypoint.py"]

Make sure that any secrets or environment variables (like AWS credentials) are available to the

flyte

user, either by setting them in the Dockerfile, passing them at runtime, or using Flyte's secret management. If you use Kubernetes secrets or Flyte secrets, ensure they are mounted or injected in a way that the non-root user can access them (e2ed6d04, a83a0635). Would you like more detail on troubleshooting the authentication error or on Flyte secret management? Sources: - e2ed6d04 - a83a0635 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 what are the options for setting

destination-dir

? i have it working using the CLI arg during

pyflyte register

, but that isn't ideal.

You can set

destination-dir

(the directory where Flyte unpacks your code for fast registration) in several ways: 1. CLI Argument: As you mentioned,

--destination-dir

can be set directly in the

pyflyte register

or

flytectl register

command. 2. Dockerfile WORKDIR: If you set

WORKDIR

in your Dockerfile, Flyte will use that as the default unless overridden. 3. ImageSpec: When using Flytekit's

ImageSpec

, you can specify the

source_root

parameter, which controls where code is copied in the image and can align with your desired destination directory. 4. Config File: There is no explicit config file option for `destination-dir`—it must be set via CLI or by aligning your Dockerfile and registration process (e2ed6d04, cf81a894). If you want to avoid the CLI flag, ensure your Dockerfile's

WORKDIR

matches where you want the code, and do not override it during registration. Would you like more detail or examples? Sources: - e2ed6d04 - cf81a894 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@ancient-wolf-19325 i tried setting

WORKDIR

to

/app

but

/root

was still used. do you know if that behavior changed in a specific version of flyte?

By default, Flyte’s fast registration and code extraction use

/root

as the destination directory unless you explicitly set

--destination-dir

during registration. This default behavior has been discussed in the community, and as of recent versions,

/root

remains the default unless overridden (e2ed6d04, ad2cb689). Setting

WORKDIR

in your Dockerfile does not automatically change Flyte’s code extraction path; you must align the

--destination-dir

with your

WORKDIR

or use the CLI flag. There is no documented Flyte version where this default changed—manual override is still required if you want a directory other than

/root

. Would you like more detail or a workaround? Sources: - e2ed6d04 - ad2cb689 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.