Help request: Dockerfile for ponzu about ponzu

[sirikon]

@nilslice If you have a Dockerfile for development and other one for production, the only difference is that one of them will include the SDKs, runtimes, compilers, or whatever is needed to actually build the project.

The production Dockerfile will just have the minimum dependencies and an already builded project ready to run.

For example, a Golang project development Dockerfile should include the Golang tools. The development one just the compiled project (the executable) and asset files if needed.

[sirikon]

I've some experience with Docker, what do you need it for?

Many projects tend to define a dockerfile for development and other one for production, I like this approach.

[nilslice]

@sirikon - I think the ability to just quickly run a golang container that installs the latest version of ponzu would be nice to have.

For people already using Docker, it seems that this is a common way for them to try out a new project.

I am not opposed to a multi-file approach if it is something people are used to, but I'll have to look for one to see how its used. Do you know of an example off hand?

[nilslice]

@sirikon - that makes sense!

[krismeister]

I'm familiar with Docker but not very familiar with GO. The docker file would probably start from Docker's official GO-Lang image, which is based on Debian.

I believe, the only pre-compiling that could happen in the public docker image would be the CLI, an individual project still needs to run from source with the full build tools, plus things like ssh/ git / curl etc.

The VOLUME feature in Docker, allows a host to persist data between deploys. It maps an outside folder into the container (think symlink).

It would be easier actually to move all persistent resources into a new folder, similar to rails a shared folder. Such as:

1. project/shared/db/ - where the 2 db files persist
2. project/shared/uploads/ - the admin uploaded files
3. is there a log file somewhere? for some reason i don't see it /var/log/ponzu-server.log on my local.

There are actually some un docker-like things about the current ponzu setup. DBs usually come from external containers, and their host/open port is routed into the container. Docker also has some nice ways to manage SSL. None the less, this project can be Dockerized.

[krismeister]

To create the public image, we do need to figure out somewhere else to put DB files and upload directory. Otherwise they will be overwritten on each docker deploy. I'm less concerned about the log, its OK if each deploy starts a new log file.

I was wrong in my above comment. For docker to handle the persistence between deploys, they actually need to move completely out of the project directory. Such as /var/ponzu/projectName/

We MAY be able to symlink the DB and upload directory into place when the docker container starts up.

[nilslice]

Hi @krismeister -

Thanks for submitting this! I am taking a look through the Dockerfile and will test it out when I have a minute to get my Docker env back in order.

Regarding the file location for data, it is possible for Docker to enable a "host" file to be read/written from inside a container, right?

You're just suggesting that we need to pick a reliable path in the host FS to keep the data and uploads?

These foreign paths will be "resolved" within the container to the local path that Ponzu assumes when starting up though, is that right?

For example, even though the file is at /var/ponzu/$PROJ/system.db, your Ponzu binary will still be able to open ./system.db as if it were in the same directory. If not, we will need to update the CLI to take a different data path.

Although not merged into master yet, there will also be a search directory which will hold the search indexes for the content types. This would need to persist between deploys as well.

Sorry for all the questions, just want to make sure I know how I can help.

[krismeister]

When I mentioned choosing a path, i meant a path in the docker container. I have to test if we can symlink these files into place. It might be do-able to have the .dockerignore file not overwrite these files from a developers local project folder.

To get back to only distributing the CLI executable. If we only distribute the CLI, can a user run all of their project code, including the GO source files, without any other system dependancies?

[nilslice]

I see. Well, the CLI is a wrapper around the go tool (compilier, package download & installer, etc) and git - which I believe is a dependency of the go tool. So I think the go tooling would be the only requirement.

[krismeister]

Since an individual project needs the full GO build tools, its not helpful to only distribute the Ponzu executable. However an individual development team can after ponzu build copy their executable into a minified Docker Container.

[nilslice]

Alright, thanks for the explanation - I definitely need to brush up on my docker skills.

So once I create the Ponzu image and push it to DockerHub, I will update the links where needed in your PR. At that point it should be ready?

[krismeister]

Once you get the docker image onto dockerhub, the end result will look like:
https://hub.docker.com/r/krismeister/ponzu/

And it is being used here:
https://github.com/ponzu-cms/examples/blob/master/docker/admin/Dockerfile#L1

I made that container by following their auto build instructions, pointing to my github ponzu dev branch.

Their autobuild instructions do make it easy, but you have to get it merged into a github repo somewhere. so you could merge right now to dev, and do the Dockerhub auto build instructions, Or you can clone my krismeister/ponzu dev branch and make a new /ponzu-cms/ponzu branch called docker do the autobuild from that.

Learning docker is a good idea, as alot of the sexy ways to integrate a restCMS can be aided greatly with other off the shelf docker containers.

[tonyalaribe]

I'm currently facing this issue. My db changes get rewritten with each new docker deploy. Can all the files be kept in a folder? so instead of ./system.db, we use ./shared/system.db so i can simply mount a persistent colum at ./shared ? or make it possible to pass the shared directory as a cli flag

[nilslice]

@tonyalaribe - can you share the pwd of your Ponzu project to the container? It wouldn't be a major change to add a CLI flag for the db location (maybe a good first PR? 🙂), but personally I have found keeping all the db files within the same directory as the binary to be really useful, especially in deployment.

I do think offering a CLI flag to customize their location would be a good feature, though keep in mind there are 2 db files - system.db and analytics.db which (I think) each would need their own path flag.

[krismeister]

These files are symlinked in the ponzu docker example here: https://github.com/ponzu-cms/examples/blob/master/docker/admin/start_admin.sh#L10.
@tonyalaribe The ponzu docker example repo should solve the persistence issue you face.

When I last touched the docker setup, I felt there was a good amount of files in /shared/ which needed to come directly from the repo and shouldn't persist on a machine by machine basis. This was part of the long discussion above. Moving anything that needs to persist between deploys into a new separate directory that is never committed to git, would make this setup much easier.

Its possible I missed some details about how to integrate into docker, @tonyalaribe if you can find a better way that would be awsome.