fix: run ghost under the production environment.

[fjmk]

Solve the issue of starting in production environment in #2

[tianon]

I still think it'd be better to document how a user can do this themselves, since this is very likely to break with future releases of Ghost (especially that really hairy sed line).

[soupdiver]

I ran into the same issue and I also don't really like the approach with sed.
I think when you have to deal with state in containers you go with special data-only container to keep this state.
So you could start a container from the same image and override the command with something like /bin/true and start the "real" container with the volumes from that data-only container.
That's a pretty common pattern.
Then you could simply add your config.js to the data-only container.
Anyway this just works half the way with the current entrypoint.sh
If I override the start command with /bin/true to get a clean exit code the content directory is not initialised because this will only happen when the command is npm start
Right now I have to accept an unnecessary running data container (when not passing NODE_ENV=production or a dirty exit code when passing the production env.

So could tar -c --one-file-system -C "$GHOST_SOURCE/content" . | tar xC "$GHOST_CONTENT"depend on something else than if [ ! -e "$GHOST_CONTENT/config.js" ] to get a clean setup running?

[yosifkit]

With the current entrypoint, this is fixed?

[tiangolo]

I have been fighting with this image for the last couple days, so I wanted to share my thoughts with you on some production related issues.

Using the container as-is "hardcodes" the base URL to "http://localhost:2368" in several places, for example when clicking on the lower left link with the name of the blog points to that "http://localhost:2368" URL.

To customize that URL it's needed to provide a config.js, and put it in /var/lib/ghost.

But for a user that wants to just start a Ghost blog with Docker without having to learn and modify how it works (what I was trying first) that would be a bit cumbersome.

Would you be against using the config.js from this comment? #2 (comment) (or something similar).

Using that config and some documentation would allow people to use Ghost and modify the base URL with an ENV var and without having to know how to write a proper config.js, knowing JS, etc.

And I don't really see why would I want to have a default config.js file with a lot of environments, at least in the simplest case. If I was trying to develop a theme from scratch (for example), at that point I would already need to write quite some code and I could provide my custom config.js with a development configuration. Also, that default config.js file doesn't support the simplest case of just deploying a Ghost blog, the default uses the "development" environment.

---

The other thing is, I don't know why is it important to run the container as a user different than root, off course I understand why in a physical server, but in a Docker container? Maybe you can point me to some reference for that or something...

But I see that there are some issues (in the issues and comments) while not running as root, e.g. #19, #15, #2, #27.

One case that I see that gave me a lot of trouble to discover (because the Node.js error was not helping much) is, a non-root user cannot bind to a port lower than 1024. So, if I tried a config.js that binds to port 80, that would throw an error and would not work.

---

I would suggest, at least to start, one of the following:

• Provide a config.js similar to the one above with an updated README to use it.
• Update the README to tell people that they need to learn how to create and provide their own config.js.
• If it is imperative to use a non-root user inside the container, update the README informing people that the config.js cannot bind to a port lower than 1024 as the container won't run as root.

I could write a PR, but I would like to hear your opinions first to direct my efforts to just one of those (if you think any of those could apply).

[tianon]

I believe #15 (comment) still sums up the current state of running the Ghost image as-is in production mode:

We traditionally take the stance that if upstream supplies a "default config", we use it. If they do not, but they do provide an example, we take the example config and adapt it as lightly as possible (hence our "sed" on top of the example file to create the initial configuration, which works fine for development deployments). What we couldn't find was a cut and dried "here's the optimal configuration you should use for your Ghost deployments", so I'm very hesitant to make any further changes to that example configuration without an explicit recommendation from upstream that we ought to deviate.

I believe upstream is working on refactoring the way they handle configuration in the upcoming release (to use nconf, if I remember correctly), but I can't find where we've discussed that previously ATM. This upstream issue looks very relevant: TryGhost/Ghost#7488

Given that there are some good notes over in #15 for now, I'm closing this, and am hopeful that the new nconf work upstream will help with this problem (at the very least, it'll change any "official" solution we come up with now). Thanks!