Extract entrypoint script to file for Apptainer compatibility#386
Conversation
Apptainer mounts the container filesystem read-only by default, so the
existing entrypoint failed in two places:
* cron could not write /var/run/crond.pid
* redis-server could not access /var/lib/redis (and on Ubuntu it loads
the system /etc/redis/redis.conf which points there)
Refactor the inline-heredoc entrypoint into entrypoint.sh and redirect
all runtime state (Redis data + pidfile, generated nginx config, nginx
pidfile + temp dirs) to RUNTIME_DIR (default /tmp/opendiakiosk), which
is writable as tmpfs under Apptainer and as overlay under Docker. cron
failure is now non-fatal so the rest of the app still starts when
scheduled cleanup is unavailable.
Docker behavior is unchanged - the queue is already configured with
appendonly=no so moving the Redis dir to a tmpfs path costs nothing.
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📝 WalkthroughWalkthroughThe PR moves container entrypoint initialization from inline Dockerfile generation to an external ChangesContainer Entrypoint and Runtime Orchestration
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
entrypoint.sh (1)
128-141: ⚡ Quick winUse absolute paths or ensure working directory context for consistency and robustness.
While the Dockerfile sets
WORKDIR /app, using relative paths likeapp.pycreates an implicit dependency on the working directory. Using/app/app.pydirectly would make the intent explicit and avoid subtle failures if the directory context changes later.Suggested fix
- streamlit run app.py --server.port "$PORT" --server.address 0.0.0.0 & + streamlit run /app/app.py --server.port "$PORT" --server.address 0.0.0.0 & ... - exec streamlit run app.py --server.address 0.0.0.0 + exec streamlit run /app/app.py --server.address 0.0.0.0🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@entrypoint.sh` around lines 128 - 141, The start-up commands use a relative path "app.py" which relies on WORKDIR; update the streamlit invocation(s) in the multi-instance loop (the lines running streamlit run app.py --server.port ... and the single-instance exec streamlit run app.py --server.address ...) to use the absolute path /app/app.py, and also ensure the nginx exec uses an absolute nginx config path (NGINX_CONF should be an absolute path or resolved before use) so both streamlit launches and nginx launch do not depend on the current working directory.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@entrypoint.sh`:
- Around line 128-141: The start-up commands use a relative path "app.py" which
relies on WORKDIR; update the streamlit invocation(s) in the multi-instance loop
(the lines running streamlit run app.py --server.port ... and the
single-instance exec streamlit run app.py --server.address ...) to use the
absolute path /app/app.py, and also ensure the nginx exec uses an absolute nginx
config path (NGINX_CONF should be an absolute path or resolved before use) so
both streamlit launches and nginx launch do not depend on the current working
directory.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: d503cf70-bab9-48f9-b2c6-b5f0a8779a94
📒 Files selected for processing (2)
Dockerfileentrypoint.sh
Summary
Refactors the container entrypoint from an inline shell script in the Dockerfile to a separate
entrypoint.shfile. This improves maintainability and adds support for running under Apptainer/Singularity containers, which mount the filesystem as read-only by default.Key Changes
New file:
entrypoint.sh— Extracted entrypoint script with improved Apptainer compatibility:RUNTIME_DIRenvironment variable (defaults to/tmp/opendiakiosk) to route all runtime state (Redis dumps, pidfiles, nginx temp dirs) to a writable location$RUNTIME_DIRinstead of system paths like/var/lib/redisand/var/runModified:
Dockerfile— Simplified entrypoint setup:RUN echoscript that generated the entrypointCOPY entrypoint.sh /app/entrypoint.shfor clarity and maintainabilityRUN mkdir -p /var/lib/redis && chown redis:redis /var/lib/redissince Redis now uses$RUNTIME_DIRImplementation Details
The key innovation is the
RUNTIME_DIRpattern: by defaulting to/tmp(which is bind-mounted as tmpfs in both Docker and Apptainer) and allowing override via environment variable, the container works seamlessly in both environments:/tmp/opendiakiosk, which is writable/tmpis writable; users can overrideRUNTIME_DIRto a persistent path if they want Redis dumps to survive container restartsThis approach eliminates the need for separate Dockerfile variants or complex conditional logic in the entrypoint itself.
https://claude.ai/code/session_01NF5Z6z8JjpuknFcDKki5KQ
Summary by CodeRabbit