You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am a bit confused as to how I am supposed to do some edits to my current theme. Even though I mounted /content, there are no files within the /themes folder.
I have issue when starting the container, I can't work on the theme in intellij due to permissions access, the uid guid used are 1000, there's no way to change that, my user is another uid guid
I have issue when starting the container, I can't work on the theme in intellij due to permissions access, the uid guid used are 1000, there's no way to change that, my user is another uid guid
The problem is that this image nukes any mounted volume's permissions with its chown/tar in docker-entrypoint.sh, which is incompatible with many setup and/or rootless containers.
I'm trying to set this up using Kubernetes, and I would like to develop my theme locally. If I mount from "./themes" to "/var/lib/ghost/content/themes", there are three ways it might go:
On a regular Docker setup, iff your host uid == 1000 (like the node user on the Docker image), everything is fine.
On a regular Docker setup, if your host uid != 1000, like @kopax has, the entrypoint will nuke your permissions, so you won't be able to edit the theme files locally (because they're not owned by your uid anymore)
On a rootless Podman/k8s setup, as recommended nowadays, the node container user with uid 1000 is mapped to host uid 100999, so it's basically like case 2, where as soon as the container starts your theme files get chown'd to 100999 and you won't be able to edit your themes on your machine.
The entrypoint script should not chown nor change any permission of its files, as it works only on a small percentage of setups, and it's a nightmare to work around on others.
For production setups, it's definitely useful, but I agree it's less than ideal for development workflows (the worpdress image has struggled with this a lot).
What I'd suggest here is to use a non-root user for the container, which will bypass the chown behavior entirely (docker run --user 1000 ...).
What I'd suggest here is to use a non-root user for the container, which will bypass the chown behavior entirely (docker run --user 1000 ...).
Not really, the tar command will try to write to /var/lib/ghost and subdirectories, and if you have a bound volume there (i.e. your theme, which should be perfectly fine if it's read only), the image won't start because tar fails.
To change file permission is very intrusive, I understand the need for something like this a couple of years ago, but now both in production (k8s has a way to define which permissions should be used to mount a volume) and dev (rootless) is a pain
Before editing your themes, you should be able to run ghost normally, then upload themes via the GUI in the admin panel.
This is not practical or useful in development workflow. I want to be able to;
Make edits on my custom theme
See them in a ghost instance that uses this theme
Commit changes
When you manually upload a theme in a local instance this workflow is broken. @pascalandy this is certainly an issue with the image as outlined quite succinctly by @1player. I understand that this is ideal for production but it is quite convoluted in development.
Perhaps this can be addressed by documentation? I am trying some pretty insane things to try and bypass the way this image works. I really dont want to fork/maintain my own image that works for me so any tips on how to avoid that would be great.
Update: It was a more ideal setup to just add a volume(s) to the given docker-compose
version: '3.1'
services:
ghost:
image: ghost:5-alpine
restart: always
volumes:
- ./content:/var/lib/ghost/content
ports:
- 8080:2368
environment:
# see https://ghost.org/docs/config/#configuration-options
database__client: mysql
database__connection__host: db
database__connection__user: root
database__connection__password: example
database__connection__database: ghost
# this url value is just an example, and is likely wrong for your environment!
url: http://localhost:8080
# contrary to the default mentioned in the linked documentation, this image defaults to NODE_ENV=production (so development mode needs to be explicitly specified if desired)
#NODE_ENV: development
db:
image: mysql:8.0
restart: always
volumes:
- ./data:/var/lib/mysql
environment:
MYSQL_ROOT_PASSWORD: example
Then you can just clone into your theme in the theme directory. It should be noted that you will need to run yarn install && yarn run dev to see live css changes.
Activity
pascalandy commentedon Apr 30, 2020
Hi,
This is not related to this docker image.
But let me try to help. You have to download the theme. Then, you must update it (it uses Handle Bar).
See https://ghost.org/docs/api/v3/handlebars-themes/
You can also ask for help on https://forum.ghost.org/c/help/6
Cheers!
lapphan commentedon Jun 26, 2020
@AlexKalopsia please provide your
docker-compose.yml.pascalandy commentedon Jun 26, 2020
Before editing your themes, you should be able to run ghost normally, then upload themes via the GUI in the admin panel.
kopax commentedon Oct 26, 2020
I have issue when starting the container, I can't work on the theme in intellij due to permissions access, the uid guid used are 1000, there's no way to change that, my user is another uid guid
pascalandy commentedon Dec 15, 2020
Can't help without details
1player commentedon May 26, 2022
The problem is that this image nukes any mounted volume's permissions with its
chown/tarindocker-entrypoint.sh, which is incompatible with many setup and/or rootless containers.I'm trying to set this up using Kubernetes, and I would like to develop my theme locally. If I mount from "./themes" to "/var/lib/ghost/content/themes", there are three ways it might go:
The entrypoint script should not chown nor change any permission of its files, as it works only on a small percentage of setups, and it's a nightmare to work around on others.
tianon commentedon May 26, 2022
For production setups, it's definitely useful, but I agree it's less than ideal for development workflows (the
worpdressimage has struggled with this a lot).What I'd suggest here is to use a non-root user for the container, which will bypass the
chownbehavior entirely (docker run --user 1000 ...).1player commentedon May 27, 2022
Not really, the
tarcommand will try to write to/var/lib/ghostand subdirectories, and if you have a bound volume there (i.e. your theme, which should be perfectly fine if it's read only), the image won't start because tar fails.jalberto commentedon Jun 10, 2022
To change file permission is very intrusive, I understand the need for something like this a couple of years ago, but now both in production (k8s has a way to define which permissions should be used to mount a volume) and dev (rootless) is a pain
jalberto commentedon Jun 10, 2022
My workaround in docker-compose:
this works fine with podman rootless
derek-adair commentedon Jun 28, 2023
This is not practical or useful in development workflow. I want to be able to;
When you manually upload a theme in a local instance this workflow is broken. @pascalandy this is certainly an issue with the image as outlined quite succinctly by @1player. I understand that this is ideal for production but it is quite convoluted in development.
Perhaps this can be addressed by documentation? I am trying some pretty insane things to try and bypass the way this image works. I really dont want to fork/maintain my own image that works for me so any tips on how to avoid that would be great.
derek-adair commentedon Jun 28, 2023
Ok, I have figured out a config that will support my desired worklow with the supplied official compose file.
The trick was to mount my theme in the compose file directly to the theme directory;
This theme will not show up in the list of themese and you must click "advanced" to select it.
derek-adair commentedon Aug 2, 2023
Update: It was a more ideal setup to just add a volume(s) to the given docker-compose
Then you can just clone into your theme in the theme directory. It should be noted that you will need to run
yarn install && yarn run devto see live css changes.