The official Ghost 6 install docs only currently cover a “new install” and “Migrating an existing Ghost-CLI site”.
They do not cover upgrading a Ghost 5 docker install. I expect that if I have a working Ghost 5.130 Docker install and switch to a Ghost 6.0 container image, everything will continue to work as it did before without further configuration changes, while the new features that require additional containers simply won’t enabled (ActivityPub, Analytics, Caddy). Is that accurate?
Since upgrades can be one-way trips, I’m hesitant to upgrade until I’m clear.
Thanks.
I tested this on my on own sites and it seems the answer is that:
Yes, if you have a working Ghost 5.130 install using a Docker image, simply replacing the image with the 6.0.4 image will result in a successful upgrade. This implies you have already handled the MySQL database separately as well as the web server piece, possibly with Nginx.
After the upgrade, the TinyBird Analytics option will be grayed out (because it’s not installed). I found the “Social Web” option was visible and appeared to be enabled, but I don’t expect to work, since the ActivityPub service was not enabled, so I disabled that.
2 Likes
I think thats still the missing piece though, how to enable activitypub if youre on the docker hub container images. When they were in the development phases for activitypub I had set up a separate server from their github and it kinda worked on my test instance. What I’ve been confused with is that what still needs done if youre using the docker hub image? Why not make a docker hub container with that whole server component if they want to keep these separate stacks.
how to enable activitypub if youre on the docker hub container images.
If I reading the Docker Compose directory, Ghost is in turn referencing the images published on Docker Hub. Which is interesting, because on Docker Hub the Ghost image says it maintained by Docker Hub, not the Ghost team and is not “official”.
How the ActivityPub container is set up can be seen in the Docker Compose file. You would need to adapt that to your environment.
Why not make a docker hub container with that whole server component if they want to keep these separate stacks
Docker best practice is to have one service per container, and use Docker “compose.yml” files when your project becomes more complex and uses several related services. So the Ghost team is following best practice there.
For self-hosters, this arrangement provides flexibility and can also help with a maintenance and security, as you get different logs for individual services, you can turn off optional services, and you can see how much memory and CPU each service is consuming.
In my case, I have several services sharing the same MySQL database, so it’s useful to me that that the MySQL service is not bundled with the Ghost service.
1 Like
interesting. I had been pulling the whole repo down for activitypub and running it. youre just pulling an image from github. I’ll have to try that.
I read a little bit more and seems i was doing the same thing, just building the container from source using the compose in the activtypub repo, there is still no documentation that I can find that details all of the setting in the environment vars in the configs if you have a setup that is not just a development environment.
yeah i dont think that example will work for a multi-tenant situation, that example is more for dev environments with everything enclosed in one. the container doesnt seem to actually run and posts this ‘no configuration file provided: not found’ in the log if im running it alone on its own box. it looks like it wants to access the ghost config for the instance youre running.