explore: non-root user for docker #1589
Conversation
WalkthroughThe pull request updates several Docker-related configurations and scripts. The CI workflow and build scripts now use a dynamic loop with curl to check backend readiness instead of fixed sleep delays. Additionally, Docker Compose files for both standard and enterprise setups replace bind mounts with named volumes, and Dockerfiles for backend and frontend services now create a non-root “app” user with specific UID/GID, set an environment variable, and configure persistent storage. Documentation in the README files has been updated to clarify Docker Compose usage under Linux and enterprise environments. Changes
Sequence Diagram(s)sequenceDiagram
participant CI as CI Workflow / Build Script
participant DC as Docker Compose
participant BE as Backend Service
CI->>DC: Start containers (build/up)
loop Check Backend Readiness
CI->>BE: Send curl request to API endpoint
BE-->>CI: Respond (ready or not)
end
CI->>DC: Proceed with initialization after readiness confirmation
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms (8)
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
try without db file
frontend
adapt to busybox
revert test
test
ab-smith
changed the title
Use named volumes trick as in docker/compose#3270 (comment)
also fix docker-compose-build.sh
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (6)
enterprise/docker-compose-build.yml (1)
26-27: Huey Service Dependency Declaration.
Adding thedepends_ondirective for the huey service ensures that the backend starts first. Please note that line 27 contains trailing spaces; removing them will clear the YAMLlint warning.🧰 Tools
🪛 YAMLlint (1.35.1)
[error] 27-27: trailing spaces
(trailing-spaces)
docker-compose.sh (1)
21-21: Extraneous Tilde Character.
Line 21 shows a tilde (or stray marker) without accompanying content. Please remove it if it is not intended to be part of the final script..github/workflows/startup-tests.yml (3)
144-147: Improved dynamic readiness check:
Using a loop withcurlto verify backend readiness is a clear improvement over a static sleep delay. Consider adding a timeout mechanism or a maximum retry counter to avoid potential infinite waits if the backend never becomes ready.
280-281: Quote environment variable expansion:
In the step that creates the backend environment variables file, the commandexport $(grep -v '^#' .env | xargs)can lead to word splitting issues. Please consider quoting the command’s output (or using a safer loop) as recommended by shellcheck (SC2046).
283-286: Consistent readiness check in enterprise tests:
The enterprise Docker Compose test’s loop for checking backend readiness mirrors the earlier change, ensuring consistency across environments. As before, adding a timeout or maximum retry counter would further safeguard against prolonged hangs.docker-compose-build.sh (1)
29-32: Dynamic backend readiness wait loop:
Switching to a dynamic wait loop usingcurlsignificantly improves the robustness of the startup process compared to a fixed delay. As a safeguard, consider implementing a timeout or maximum retry limit to handle the scenario where the backend does not become ready.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
.github/workflows/startup-tests.yml(2 hunks)README.md(1 hunks)backend/Dockerfile(2 hunks)docker-compose-build.sh(2 hunks)docker-compose-build.yml(4 hunks)docker-compose.sh(1 hunks)docker-compose.yml(4 hunks)enterprise/README.md(1 hunks)enterprise/backend/Dockerfile(2 hunks)enterprise/docker-compose-build.yml(3 hunks)enterprise/frontend/Dockerfile(1 hunks)frontend/Dockerfile(1 hunks)
🧰 Additional context used
🪛 YAMLlint (1.35.1)
enterprise/docker-compose-build.yml
[error] 27-27: trailing spaces
(trailing-spaces)
🪛 actionlint (1.7.4)
.github/workflows/startup-tests.yml
278-278: shellcheck reported issue in this script: SC2046:warning:2:8: Quote this to prevent word splitting
(shellcheck)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: enterprise-functional-tests (3.12, chromium)
🔇 Additional comments (27)
README.md (1)
276-278: Enhanced Documentation for Linux Bind-Mount Ownership
The newly added note helps clarify that when using a bind-mount on Linux, users need to adjust ownership viachown 1001:1001 dbto match the non-root user configuration. This is a valuable clarification that aligns the README with the updated Dockerfile settings.frontend/Dockerfile (1)
24-25: Implement Non-Root User in Frontend Container
The addition of the command to create a group and user (appwith UID/GID 1001) and switching the process context viaUSER appimproves container security by preventing operations under the root user. Ensure that all file permissions required for runtime operations are accessible by theappuser.enterprise/frontend/Dockerfile (1)
27-29: Secure Enterprise Frontend with Non-Root User Setup
Creating a non-root user (appwith UID/GID 1001) and switching to that user usingUSER appis a commendable security enhancement. Confirm that any files or directories needing write permissions are appropriately set up for theappuser to avoid permission issues during runtime.enterprise/backend/Dockerfile (2)
8-9: Configure Environment Variables for Consistency
Introducing the environment variableDJANGO_SETTINGS_MODULE=enterprise_core.settingsand settingHOME=/tmpassists with runtime consistency and isolation. Make sure these variable settings are compatible with other deployment environments.
57-59: Non-Root User Creation and Volume Declaration
Creating theappuser and group (UID/GID 1001), ensuring the/code/dbdirectory exists with correct ownership, and designating it as a persistent volume (viaVOLUME /code/db) collectively enhance the container’s security and data management. Verify that these changes propagate to any scripts or configurations that rely on directory permissions.backend/Dockerfile (2)
8-9: Streamline Environment Variables for Backend Container
SettingHOME=/tmp/alongside establishingPOETRY_CACHE_DIR=/tmp/poetry_cacheis a solid move to isolate runtime artifacts and temporary data. Ensure that these environment settings do not conflict with any application-specific configurations.
51-53: Adopt Non-Root User and Define Persistent Volume
The introduction of non-root user creation commands (groupaddanduseraddforappwith UID/GID 1001), creating the/code/dbdirectory with the appropriate ownership, and exposing the directory as a volume (VOLUME /code/db) significantly bolster the container’s security posture and data persistence. Double-check that all services interacting with this volume account for the updated permissions.enterprise/docker-compose-build.yml (4)
1-3: Volume Definitions Verified.
The named volumesdbandcaddy_dataare correctly declared at the top of the file, setting the foundation for standardized volume management across services.
18-20: Backend Service Volume Mapping.
The backend service now mounts the named volumedbto/code/db, which enhances portability by avoiding host-dependent bind mounts.
35-35: Huey Service Volume Mapping.
Thehueyservice’s volume configuration using thedbnamed volume is consistent with the backend configuration.
65-66: Caddy Service Volume Mapping Update.
The caddy service correctly uses thecaddy_datanamed volume for/data, aligning it with the overall volume management strategy.docker-compose.yml (4)
1-3: Volumes Section Standardization.
The volumes section now declaresdbandcaddy_dataas named volumes, replacing host bind mounts for improved consistency and maintenance.
16-17: Backend Service Volume Mapping.
The backend service mounts thedbnamed volume to/code/db, which promotes a more portable and predictable environment configuration.
39-40: Huey Service Volume Configuration.
The huey service similarly employs thedbvolume for its data, ensuring uniformity across services.
71-72: Caddy Service Volume Mapping.
Mapping the caddy service’s volume tocaddy_data:/dataaligns with the new volume management strategy and mirrors the configuration in the enterprise compose file.docker-compose-build.yml (4)
1-3: Named Volumes Declaration.
The volumes section at the top of the file correctly definesdbandcaddy_dataas named volumes, ensuring consistency in storage management across services.
15-16: Backend Service Volume Mapping.
The backend service mounts thedbvolume to/code/db, streamlining the transition away from bind mounts and enhancing container portability.
31-31: Huey Service Volume Mapping.
The huey service is configured to use the named volumedbfor its storage, following the same pattern as the backend service.
60-61: Caddy Service Volume Configuration.
Assigning the named volumecaddy_datato the caddy service for/datais consistent with the changes in other compose files and ensures better data isolation.docker-compose.sh (3)
1-8: Simplified Initialization Process.
The script now directly pulls images and starts the containers without conditionally checking for an existingdbdirectory. This simplification aligns with the new Docker volume strategy.
9-13: Dynamic Backend Readiness Check.
Introducing a loop withcurlto wait for the backend to become ready improves robustness by dynamically verifying service availability before proceeding.
14-20: Superuser Creation and Completion Messages.
The steps for creating a superuser and displaying progress messages are clear and sequential, ensuring users understand the initialization flow.enterprise/README.md (2)
7-7: Clarify Repository Directory Requirement.
Updating the instruction to ensure the user is in the top directory of the repository is helpful for avoiding path issues when running Docker commands.
12-13: Streamlined Docker Compose Command.
The revised command (docker compose-build.sh enterprise/docker-compose-build.yml) simplifies the Docker startup process and aligns with recent script modifications.docker-compose-build.sh (3)
4-4: Optional Docker Compose file parameter:
UsingDOCKER_COMPOSE_FILE="${1:-docker-compose-build.yml}"provides flexibility to specify an alternative Docker Compose file when needed. This change enhances the script’s usability.
19-19: Early metadata preparation:
Callingprepare_meta_fileat the beginning ensures that the build metadata is updated prior to container operations, which supports consistency and traceability.
34-39: Clear final messaging:
The final output messages clearly communicate the state and next steps to the user. The instructions are helpful and consistent with the previous changes.
test on backend
Summary by CodeRabbit
New Features
Documentation
Chores