
Ask HN: How to handle content of a flat-file CMS in Docker images? - Kovah
Hi HN Community,<p>I currently work on a project that runs with Kirby, a flat file CMS. Means: all content is saved in files inside the project structure. The project should be built as a Docker image and deployed to the server afterwards.<p>I would like to know how a good solution could look like that handles the changing content files inside the Docker containers?<p>Current evaluated solutions:<p>- save them in shared folders outside of the Docker containers, via volumes.<p>- handle them via Git and store them in a submodule, changes are commited with the Autogit Kirby plugin.<p>What are your thoughts? :)
======
tedmiston
How are you running the Docker containers in production? e.g., Docker Compose
on a single server, Kubernetes, something else, etc

For prod, if you are trying to keep runtime simple, I would bake the content
into the Docker containers and keep the containers immutable as others have
suggested. This works especially well if you're deploying on a FaaS platform
like Zeit Now. Baking the content into the image makes scaling effortless if
you need it.

For local dev, I would just use a docker volume or bind mount.

------
ecesena
Keep the container immutable.

So more likely solution 2, the important thing is that you regenerate the
container image every time you deploy changes. If you care about faster
builds, keep the cmd to pull content towards the end of your Dockerfile.

Immutable containers can be relaunched even when your data is not available,
and new images can’t be built. It’s rare, for sure, but even s3 goes down.

Edit: of course for development it’s easier to mount a volume.

------
steigr
volume solution sounds good because that’s state which should be kept outside.
Think of a Kirby-Runtime-image providing your site from docker volume. Share
the volume between kirby container and utility container pulling the git bits
into the volume for devision of concerns (keeps git and credentials in
separate container).

------
zoobab
Just rebuild your container each time you change one bit.

And get gitlab-ci to redeploy it automatically to a kubernetes cluster each
time it changes.

~~~
Kovah
This wouldn't work as content is also changed while the site is running. That
means content is changed inside the container but won't be pushed everywhere
then so the next build would override the changes made.

~~~
gexla
I think you have to fight pretty hard to justify using Docker. If you don't
know why you would need it or how you would use it, then it's possible that
you aren't ready for it yet.

Keep in mind that development Docker and production Docker are two different
worlds. There are things which Docker brings to the table in both worlds and
the way you use it is different in both. It's quite possible that it's really
helpful for development but not yet needed for production.

In your case, you would probably be better off outsourcing the plumbing of
your hosting to a service such as Netlify or Heroku.

If you still have questions, a better place to check would be one of the
StackExchange sites. Post your question there or find a similar question which
has already been answered.

~~~
Kovah
Unfortunately, it was neither my decision to use that CMS nor to use Docker
for deployments. But thank you for the input.

