Publish image to container registries #163
Open
+650
−521
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add Github Action for Container build and push Limit number of container layers and reduce size Update COPY chmod to use octal Stop copying DOCS directory into container Reduce number of production container layers Remove linux/arm64 container platform Convert django container to multi-stage build Reduction of image from ~1GB to <550MB Conslidate production/local docker-compose/Dockerfile Move compose/production/* into parent compose/ folder Remove defunct compose/local folder Remove sharing lock from cache mount on RUN The cache was empty when using a `locked` sharing type. Reverting to the default sharing of `shared` as the build should not be affected with the current workflow. https://github.com/moby/buildkit/blob/f2a6e83adcb0295099870489b76d3ce74d6f7f42/frontend/dockerfile/docs/syntax.md#run---mounttypecache > This mount type allows the build container to cache directories for compilers and package managers. |Option |Description| |---------------------|-----------| |`sharing` | One of `shared`, `private`, or `locked`. Defaults to `shared`. A `shared` cache mount can be used concurrently by multiple writers. `private` creates a new mount if there are multiple writers. `locked` pauses the second writer until the first one releases the mount.| Update workflow to run on 'master' branch Limit GITHUB_TOKEN permissions for job Only push the container on push and schedule events ghaction-docker-meta action moved from crazy-max to docker org https://github.com/docker/metadata-action/releases/tag/v3.0.0 Use bind mount rather than cache for wheels cache is not guaranteed. build the wheels and allow pip to cache during the process. bind mount the wheel-dir when installing in django stage Consolidate start commands Remove extraneous instructions from Dockerfile - no need to install the requirements in the build stage - only build the wheels - gecos is for storing metadata about a user (full name, phone number...) - copy of requirements from build is now handled transparently through a bind mount without requiring the additional layer - du of /tmp/wheels was only for debugging the cache mount which is now a bind mount - /tmp/requirements is a bind mount so it does not need to be removed from the stage Cache first stage of multi-stage build By default the mode is set to `min`, which only exports layers to the cache in the final build stage. We want to cache the first stage in order to not always build wheels. Specify ghostwriter:2.2 image in production.yml Add missing EOF newline to docker components Update to default compose in run-unit-tests github workflow job local.yml was replaced with docker-compose.override.yml which is automatically applied when no other compose files are specified
arledesma
force-pushed
the
feature/push-to-container-registry
branch
8 times, most recently
from
a8f733b to
b3a2e47
Compare
arledesma
force-pushed
the
feature/push-to-container-registry
branch
11 times, most recently
from
2c1f377 to
e574436
Compare
arledesma
changed the title
Author
|
@chrismaddalena let me know if there is anything else that I can expand on or if you need anything changed. |
arledesma
force-pushed
the
feature/push-to-container-registry
branch
from
3fb8cdf to
1c047d5
Compare
Author
|
@chrismaddalena I have gone ahead and rebased this branch based on what is currently in master. We would like to be able to deploy an official image of Ghostwriter in the near future, so is there anything else that you would like to see in order to get this merged? |
Collaborator
|
@arledesma Hey! Life has been busy so I haven't had a chance to give this a close look. Getting images on DockerHub is high on my list, so I'll take a look as soon as I can. |
arledesma
force-pushed
the
feature/push-to-container-registry
branch
from
1c047d5 to
0172a9e
Compare
|
Any updates for this? I would like to build a helm chart for this app and I need a public docker image to do that. |
|
Hey @chrismaddalena, any chance for this feature to be available in the future? It would be a lot easier to install Ghostwriter if you publish a docker image, as the community could help to create a helm chart for it. |
Collaborator
|
Yes, it's something we can look at now. The files have changed since this PR, so it would not work as is. I'm all for publishing images to make things easier. |
ColonelThirtyTwo
added a commit
to ColonelThirtyTwo/Ghostwriter
that referenced
this pull request
Dec 11, 2025
Heavily baed on Anthony Ledesma's PR (GhostManager#163), this builds the Python wheels in a separate stage, so that the published docker image does not have the packages for building or the source codes taking up space. The Django image has shrunk from roughly 2gb to 400mb.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In order to enable quick development and deployment, without requiring an hour long build, this PR will enable publishing to a container registry via configurations setup in the github repository secrets.
When running through a proof of concept with the current solution we found that there was ambiguity due to completely different solutions for
localvsproduction.This PR attempts to alleviate some of that ambiguity by:
compose/localandcompose/productiondirectories into onlycompose.docker-compose.ymllocal.yml->docker-compose.override.ymlwhich is automatically applieddocker-compose up -dautomatically starts local servicesdocker-compose up -d --buildbuilds and starts local services (should only be required for changes to requirements.txt)docker-compose.dev.ymlextendsdocker-compose.ymlfor debuggingdocker-compose -f docker-compose.yml -f production.yml up -dautomatically starts local services with debuggingdocker-compose -f docker-compose.yml -f production.yml up -d --buildbuilds and starts local services (should only be required for changes to requirements.txt)production.ymlextendsdocker-compose.ymldocker-compose -f docker-compose.yml -f production.yml pullpulls the latest referenced imagesdocker-compose -f docker-compose.yml -f production.yml up -dstarts production services, including nginxdocker-compose -f docker-compose.yml -f production.yml up -d --force-recreaterestarts production servicesbuildbut instead point at a stableimagethat has been published (currently set to2.2)Dockerfileinto a multi-stage build, utilizing aSTAGEbuild argument to determine which stages will be executed..gitattributesto help ensure that files are committed with the correct LF EOL. While this does not explicitly ensure that windows users will never see odd behavior it will help protect the files within the repository.github action
A github action workflow has been added that will build local branches and push to GitHub Container Registry and/or Docker Hub
examples:
The meta step will generate a number of labels, including semantic version/latest/edge and branch (for your repository)
The semantic version requires a valid semantic version as a tag to be pushed. Multiple labels will be produced from that in order to enable rolling images. e.g.
2,2.2, and2.2.1could all point at the same image. If2.2.2is subsequently pushed then both2and2.2will then point at the same image as2.2.2while2.2.1remains in place. When a new tag is pushed then that image will replace thelatestlabel. This will hopefully enable users to choose how much risk they are willing to accept during their production deployments by explicitly referencing a specific label.Branch labels can also be used, such as
ghostwriter:masterorghostwriter:edgewhereedgeis the latest commit on the default branch.A build is also scheduled to occur at 03:00 on the 1st and 15th days of the month. These should produce an image with a label in the format of
YYYYMMDD. These builds can be useful to help ensure that any underlying system packages are updated within the container to assist when there may be lulls in development work within this repository.Additionally this further addresses #143 by explicitly configuring the nginx service volumes of
mediaandstaticfilesto setread_onlyandnocopy:https://docs.docker.com/compose/compose-file/compose-file-v3/#volumes