Is there a particular reason why you want to put this into your Dockerfile?
The smoother way in my eyes (and how I have previously made storage adapters work in Docker) would be classic bind mounts.
E.g. put the storage adapter in a location on your host machine and install dependencies there, then mount it in your compose file (or docker run) into /content/adapters.
Thanks @jannis the main reason is to build a custom image where I change the storage adapter to cloudinary instead of using the default file storage options since that’s not a good option during production, containers can crash and all data in them will be lost especially if you’re using kubernetes
If your only worry is losing data on container crashes, a storage adapter is the wrong approach. A simple docker volume would solve that problem.
Also, keep in mind that storage adapters do not replace local file systems. Ghost persists logs, theme files, data, etc. outside of the storage adapters.
If you decide to go ahead with it, your question needs to be more specific.
From a general perspective, installing the storage adapter can happen at any point of your Dockerfile. It should be available when the container actually starts.
ok @jannis we will be using kubernetes for hosting since we want to use next.js to manage the frontend side of things. this means if I want to use volumes, I will have to either opt in for hostpath on the node or go for permenanent option like aws but we will be using cloudinary for other things so I want to use that for managing image and file storage on ghost instead.
Running Ghost on Kubernetes isn’t trivial, since Ghost does store data on the file system. It is not a stateless system.
Take a look here at the documentation:
The storage layer is used to store images uploaded from the Ghost Admin UI, API, or when images are included in a zip file uploaded via the importer.
So, you can include your storage adapter in your Dockerfile. However, it will not solve the issue of running Ghost in a Kubernetes environment.
The only thing it will do is store uploads of any kind (media, images, files) in your storage adapter’s service.
Now, given that you wan to run Ghost in headless mode, themes aren’t going to be an issue for you. But logs might be. And routing through routes.yaml might be impacted.
If you’re set on running Ghost in Kubernetes, I highly recommend having a look at @ngeorger’s project here:
This is one of the most robust setups I have seen and could inspire you to build out your own setup.
But again, you will run into funny issues if you disregard the local file system and rely on a storage adapter alone.
Haha I am not saying you shouldn’t run it in a Kubernetes cluster. You just need to be aware of the implications.
Personally, I find running Ghost in a Docker compose stack the easiest, by far, but if you already have a K8 cluster for other stuff, I wouldn’t set up a whole new infrastructure just for Ghost.
Thanks for the feedback @jannis I really appreciate your patience. we have 2 clusters since we’re building a little bigger system and I find it a little conducive adding it to one of my clusters. thanks for the information on how to host ghost on kubernetes. This will really help.
@Antwi_Erasmus Tip: You could mount an ephemeral storage alongside an adapter to minimize conflicts, but you always need to have a filesystem (virtual or real) to allow Ghost works normally.
I really appreciate your patience. we have 2 clusters since we’re building a little bigger system and I find it a little conducive adding it to one of my clusters. thanks for the information on how to host ghost on kubernetes. This will really help. 
