Closed pascalandy closed 6 years ago
It seems cool. I never checked the official images but I think we can switch folders to the official ones.
I will do it in the coming days :)
Thanks a lot for your contribution.
Thanks for caring. I asked the docker maintainers about switching to a multi-build Dockerfile. It's a no-go as multi-stage builds are not supported for all docker official images at this point (docker-CE VS docker EE pacing).
When it will be, I'm sure your work will be useful to the community. I also look with great care to your work and it's very well executed. I don't want to break all my workflows and bash-scripts and that's what is holding me to use your setup.
Many cheers! Pascal
Just pushed into the master (not tagged yet. I prefer to test it a little bit before to tag for an "official image"). I checked the official Docker to see the differences (except the multi stage... and thanks for your information). What I would like on my side is to keep environment variables to prevent static docker container configuration. With environment variables (used on the docker command line) you can run multiple blog on the same host with the same image (even if I think the only variable we need to expose is the WEB_URL... all others can be kept internally).
Enjoy the Docker... I'm still using it for my blog... so it will be updated quite often :)
I just updated my blog with this version. All is good.
I updated the README.md file with some information about things that could change for you too and repushed the 1.16.2 tag with these changes.
Enjoy
You rock!! Will test and let you know as well :)
Little glitch here
About the server_port you mean? It should remain in that way cause the final value into the json will be a number.
Or I can change the replace to replace even the " char.
What do you think? Keep the error in the original file or change the replace? :D
Marco
On Sun, Nov 5, 2017 at 6:28 PM, Pascal Andy notifications@github.com wrote:
Little glitch here [image: screen shot 2017-11-05 at 12 27 27 pm] https://user-images.githubusercontent.com/6694151/32417260-c26b38ba-c224-11e7-9272-b4d1686b05b2.png
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/mmornati/docker-ghostblog/issues/6#issuecomment-341989963, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIgO8-vuBTHhDoIyo7FySs3HFvQe3XFks5szfAhgaJpZM4P9-Ko .
Yes
About the server_port you mean?
Also, can you rephrase this
Or I can change the replace to replace even the " char.
Yes sorry. Actually in the run-ghost.sh file I'm replacing the variables into the config.production.json file with the environment variable values:
What I can do, to remove error into the original configuration file, is to change the replacement line. Should be something like this, but I have to test:
sed -i "s|\"__SERVER_PORT__\"|$SERVER_PORT|g" $CONFIG
LGTM
Great. Updated, tested and pushed to the latest image. It works and no error reported by VisualStudio code (you are using too :P)
Do you confirm you can run the image when you mount a volume?
docker run -d -p 80:2368 mmornati/docker-ghostblog
docker run -d -p 80:2368 -v /Users/localpath/data:/var/lib/ghost/content mmornati/docker-ghostblog
Same behavior with the image I built.
I have a doubt that it might be related to permissions.
# Install Ghost
RUN addgroup -S -g 1276 $GHOST_USER && \
adduser -S -h $GHOST_INSTALL -G $GHOST_USER -u 1276 $GHOST_USER
As I mentioned in the readme there is a little difference than the previous image due to the "content" subfolder. Try to run using:
docker run -d -p 80:2368 -v /Users/localpath/data/content:/var/lib/ghost/content mmornati/docker-ghostblog
It should work.
This is the path I'm using and it's not working /Users/localpath/data/content:/var/lib/ghost/content
The official ghost image use the node user. I'm wondering if this could be related.
If you check the log of your Docker (docker logs containerID) can you see anything useful?
In my test I just use the same data folder that the previous version of the docker. All the files where owned by the ghost user.
Are you connecting to a data folder used with a different image?
On Nov 5, 2017 20:10, "Pascal Andy" notifications@github.com wrote:
This is the path I'm using and it's not working /Users/localpath/data/content:/var/lib/ghost/content
The official ghost image use https://github.com/docker-library/ghost/blob/a5c9dd0d5872eaa1fd7ae7d4d486852489f0a586/1/alpine/Dockerfile#L24 the node user. I'm wondering if this could be related :)
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/mmornati/docker-ghostblog/issues/6#issuecomment-341997019, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIgO3V9jUlD9A21c5cXJlnPEhkGwJvPks5szgg0gaJpZM4P9-Ko .
I think the node user is contained into the original node-alpine image. I can change the user too... But we have to chown to the right one then.
Let me check.
On Nov 5, 2017 20:13, "Marco Mornati" ilmorna@gmail.com wrote:
If you check the log of your Docker (docker logs containerID) can you see anything useful?
In my test I just use the same data folder that the previous version of the docker. All the files where owned by the ghost user.
Are you connecting to a data folder used with a different image?
On Nov 5, 2017 20:10, "Pascal Andy" notifications@github.com wrote:
This is the path I'm using and it's not working /Users/localpath/data/content:/var/lib/ghost/content
The official ghost image use https://github.com/docker-library/ghost/blob/a5c9dd0d5872eaa1fd7ae7d4d486852489f0a586/1/alpine/Dockerfile#L24 the node user. I'm wondering if this could be related :)
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/mmornati/docker-ghostblog/issues/6#issuecomment-341997019, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIgO3V9jUlD9A21c5cXJlnPEhkGwJvPks5szgg0gaJpZM4P9-Ko .
I'm using an empty data folder on my local machine.
yes it is:
I think the node user is contained into the original node-alpine image.
The docker logs shows that the container cannot find the path when I mount the container.
It is the same error I had in my first test and it is was related to the content subfolder. What is the content of your /Users/localpath/data/content folder? Do you have the logs folder inside or it is a completely new folder?
Ok. Got it (just re-reading your message). I removed that part thinking I-dont-know-why it was useless. I'm fixing it and pushing in a couple of minutes. Stay tuned.
Glad to report that so far it's working as expected :1st_place_medal:
Please buzz me if I can test future updates.
Yes sure thanks.
I just noticed I can half reduce the image size. i'm working on it :)
On Sun, Nov 5, 2017 at 9:49 PM, Pascal Andy notifications@github.com wrote:
Glad to report that so far it's working as expected 🥇
Please buzz if I can test future updates.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/mmornati/docker-ghostblog/issues/6#issuecomment-342004279, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIgO7Z68y2i83GqcD516KCz0Y6owe9qks5szh9MgaJpZM4P9-Ko .
Wait what!? Are you saying you can reduce it to 185 MO
?
The official image is 454 MO
Your actual image is 273 MO
In the layer size I noticed the "chown" on ghost installation files is just doubled the size creating a new Docker layer where all the files, originally owned by the root user, are not owned by the ghost one.
I'm trying to create them directly with the right ownership... but it seems the multistage "copy-from" is erasing the owner and give all the files to the root user.
Oh yes. Thanks Docker!
COPY --from=ghost-builder --chown=ghost $GHOST_INSTALL $GHOST_INSTALL
The final image size:
The size is not the same than the official image, but the database migration is in a second image (which is actually 318Mb... but I can half reduce it too). What I though is that the migration was not necessary in the blog running container... it is a tool to use only during an upgrade.
But yeah... any case 164Mb vs 454Mb... I think I will keep mine 🥇
Here you are the final sizes of all the images
This is rrrr-eally good!
Also, I don't know if you are aware of Zeit pkg. It allows dev to build a binary out of node projects. See an example here
I didn't find a way to make it work with Ghost yet.
Thats good man... you are giving me a new challenge :)
No i didn't know about it... I will start checking from the url you provided. Really Thanks!!
I think it is not working right now due to this:
As it is explained on the pkg GitHub page, all this dynamic inclusions are not supported and they should be explicit into the package.json file. It should be done directly on the Ghost project.
I could try to propose a pull request about it.
Creating a package with (almost?) anything inside it is actually 124Mb. So I think the image with what you are proposing could be 126Mb using a simple alpine.
This is great Marco! I confirm the image is running smoothly.
But yeah... any case 164Mb vs 454Mb... I think I will keep mine
I tried to run the image on my existing setup and now I'm getting permission issues.
I think it would make sense to use the owner node
used in the official image.
That would ensure the drop-in replacement goal :-p
I think so too.
I will update it this evening.
On Nov 6, 2017 2:58 PM, "Pascal Andy" notifications@github.com wrote:
I tried to run the image on my existing setup and now I'm getting permission issues. I think it would make sense to use the owner node used in the official image.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/mmornati/docker-ghostblog/issues/6#issuecomment-342155840, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIgO2tgUNboz7mbxGxFhmH6xXSOpi2hks5szxBpgaJpZM4P9-Ko .
Just delivered the new image version which is using the node user instead the ghost one. Let me know if all is ok for you. For you information Issue #7
EDIT (2017-10-22_22h54)
Hi,
Here is my 5 cents. May I suggest that the container's path follows the same paths as the official docker image? This way your container would be a drop-replacement to the official docker image :)
I'm still not clever enough to understand why the official image use:
and why we need to use symlink between them. In any case, I prefer to follow the directories directed by the official image. Many people could test it easily in their stack and everyone would benefit.
How does it sound?
Cheers!