Add production Dockerfile and ci image upload workflow #70
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #70 +/- ##
========================================
Coverage 98.09% 98.09%
========================================
Files 21 21
Lines 368 368
========================================
Hits 361 361
Misses 7 7 ☔ View full report in Codecov by Sentry. |
| file: ./Dockerfile.prod | ||
| push: true | ||
| tags: ${{ steps.meta.outputs.tags }} | ||
| labels: ${{ steps.meta.outputs.labels }} |
There was a problem hiding this comment.
Missing newline at end of file
| labels: ${{ steps.meta.outputs.labels }} | |
| labels: ${{ steps.meta.outputs.labels }} | |
| @@ -106,3 +106,34 @@ jobs: | |||
| - name: Output docker logs (minio) | |||
| if: failure() | |||
| run: docker logs object-storage-api-minio-1 | |||
| docker: | |||
There was a problem hiding this comment.
If you like the idea of pushing the image to Harbor only when the CI workflow is manually run then you might want to look at the CI workflow file in ral-facilities/scigateway-auth#134 and make those changes here.
| @@ -0,0 +1,28 @@ | |||
| FROM python:3.12.7-alpine3.20@sha256:edd1d8559c585e1e9a9b79de44ac27f8ac32cb0c7323e112ae6870ceeecd8dbf AS builder | |||
There was a problem hiding this comment.
You can probably get away with one stage as I don't think it would make a massive difference in this case.
| COPY --from=builder /usr/local/lib/python3.12/site-packages /usr/local/lib/python3.12/site-packages | ||
| COPY --from=builder /usr/local/bin /usr/local/bin | ||
|
|
||
| COPY README.md ./ |
There was a problem hiding this comment.
Copying the README is not needed.
| RUN set -eux; \ | ||
| \ | ||
| # Create loging.ini from its .example file \ | ||
| cp object_storage_api/logging.example.ini object_storage_api/logging.ini; |
There was a problem hiding this comment.
We don't do this in other projects. We have instructions to tell the user to create the file manually before building the image. I think we should stay consistent.
| # Create loging.ini from its .example file \ | ||
| cp object_storage_api/logging.example.ini object_storage_api/logging.ini; | ||
|
|
||
| USER nobody |
There was a problem hiding this comment.
Wasn't aware of this user. We manually create a non-root user and group in other projects. I will need to look into this a bit more because if we can just use nobody then it would save us from creating non-root users. Let me know if you did any research on this and what you found out.
Update:
I had a chat with Alan and we decided not to use the nobody user and group. We should continue to manually create a non-root user and group like is the case with some of our projects and many popular Docker images.
|
|
||
| USER nobody | ||
|
|
||
| CMD ["uvicorn", "object_storage_api.main:app", "--app-dir", "/object-storage-api-run", "--host", "0.0.0.0", "--port", "8000"] |
There was a problem hiding this comment.
We recently started using the FastAPI CLI CLI command line program, which internally uses a production-ready Uvicorn server, as that now seems to be the recommended way by FastAPI of running apps for, both, local development and production.
There was a problem hiding this comment.
You might want to look at the Dockerfile in ral-facilities/scigateway-auth#134 and what I did there. If you like what I did then it would be nice to keep things consistent (thoughts on it in that PR are welcome). It just means that we can have a single file with multiple stages/targets.
Description
Enter a description of the changes here
Testing instructions
Add a set up instructions describing how the reviewer should test the code
Agile board tracking
closes #5