Ask HN: How to handle content of a flat-file CMS in Docker images? | Hacker News Reader

Ask HN: How to handle content of a flat-file CMS in Docker images?

2 pointsKovah9 comments

Hi HN Community,

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.

I would like to know how a good solution could look like that handles the changing content files inside the Docker containers?

Current evaluated solutions:

- save them in shared folders outside of the Docker containers, via volumes.

- handle them via Git and store them in a submodule, changes are commited with the Autogit Kirby plugin.

What are your thoughts? :)

View on HN

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.

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.

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).

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.

This is what I was going to post before zoobab beat me to it. I'm not a guru with Docker, but this is what I would do. Make use of automation and just rebuild as much as needed.

Shared volumes are good for development though.

Some tips: put the content that changes at the end of your Dockerfile so that you use caching at maximum. It also helps to only push the layers that have changed.

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.

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.

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

Reply on news.ycombinator.com