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

Question: Container file system permissions #1210

Open
morremeyer opened this issue Jan 11, 2024 · 3 comments
Open

Question: Container file system permissions #1210

morremeyer opened this issue Jan 11, 2024 · 3 comments

Comments

@morremeyer
Copy link

Hey everyone!

For https://github.com/envelope-zero/backend, we recently started using goreleaser with ko to build the image for multiple architectures. We currently use the default image, cgr.dev/chainguard/static to get the benefit of running rootless.

The Envelope Zero backend uses an sqlite database that is at data/gorm.db relative to the binary.

For some environments, this works great, e.g. kubernetes, where users mount a volume with the correct permissions for the nonroot user.

For other environments however, this does not work. For example in docker-compose and GitHub actions service containers, we cannot set the owner of a volume mount directory.

The default way for a docker build would be to create the needed data directory and chown it in the Dockerfile.
However, since ko does not use a Dockerfile, that is not possible.

Is there any guidance for how to solve this neatly, preferably without maintaining our own base image?
Thanks in advance for any ideas or feedback you might have!

@ipince
Copy link

ipince commented Jan 18, 2024

This also seems to be a problem when deploying images onto Google Cloud Run. Using GCP's default image (i.e. building from source with gcloud run deploy --source .) gives you read/write access to the (ephemeral) filesystem, while using ko's default seems to only give readonly access.

Copy link

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Keep fresh with the 'lifecycle/frozen' label.

@morremeyer
Copy link
Author

still an issue

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

No branches or pull requests

2 participants