Docker container for Vivliostyle

[Eliot Kimber]

In the context of supporting the pdf-css-page Open Toolkit plugin in my growing system of DITA-related Docker containers, I would to set up a pair of Docker containers for Vivliostyle, reflecting the full Vivliostyle package, to be hosted on the public Docker Hub site. This will then make it possible to provision Vivliostyle quickly and easily using Docker, e.g.:

  docker run -v /Users/ekimber/temp/out:/opt/vivlio/out vivlio/vivliostyle --source .. --out .. --style .. 

Which would automatically download the Vivliostyle container if it's not already present in the host environment.

I would like to use the namespace "vivlio" for the container, e.g. "vivlio/vivliostyle".

I'm happy to maintain the Docker package definition but would also be happy to contribute it back to the project.

My standard practice at the moment is to set up a single GitHub repository that defines two containers: a "base" container that does not define any volumes, a "working" container that defines whatever volumes are appropriate for the software so that other tools can use it or so that it has a place to put files.

In the case of Vivliostyle the installation directory needs to be a volume so other containers can run the executable. I haven't looked closely at the configuration details for Vivliostyle but I'm guessing there needs to be access to fonts on the host machine and other configuration details. That also requires providing a volume that can be used as a mount point for host-provided directories or supplied by other containers (for example, you might have container that contains just fonts so you can manage your available font sets separate from other containers).

I just need somebody from the Vivliostyle project to say "yes" to my request to create containers in the "vivlio" namespace. I'll create the GitHub project in the DITA Community organization unless there's a better place for me to create it.

Thanks,

Eliot

[filtered]

Docker is really not the solution for software distribution. What problem does a Docker container solve here  -  except more boilerplate...what is easier than installing

a RPM? As maintainer of 

https://pypi.python.org/pypi/pp.server/

I maintain a Docker image with various converters...building, testing and updating the image is a pita..

-aj

--
You received this message because you are subscribed to the Google Groups "Vivliostyle Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vivliostyle...@googlegroups.com.
To post to this group, send email to vivli...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vivliostyle/bc141f59-1daf-476f-bfa3-9b3f83733e2b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Eliot Kimber]

In isolation I agree that a Docker container doesn't offer much value over just installing the product but that's not my use case.

My use case is using Vivliostyle in concert with a plugin integrated with the DITA Open Toolkit where the Toolkit is then integrated with a containerized CI server (among other components). See the DITA For Small Teams project (http://dita-for-small-teams.org).

In that context it makes perfect sense because now I have a system of containers that provide all the system components and they can be fetched and run on any platform with a single command using docker-compose. 

The docker configuration file for something like Vivliostyle is pretty simple to define and maintain and Docker automatic builds remove a lot of the effort in keeping the images up to date (that is, just create a new branch for a new container image version, update the Dockerfile as needed (e.g., to refer to a specific version of the image to install), add the configuration to your Docker Hub automatic build, and push to GitHub. Done.

I have put together a set of Docker containers that provide pre-configured DITA OT instances that can be used from the command line with no additional effort. I want Vivliostyle to play in that environment. 

Cheers,

Eliot

[Florian Rivoal]

Hi,

Thanks a lot for this initiative. We agree that Docker is not the most appropriate way to distribute this kind of software in the general sense, but it does make sense in certain specialized scenarios, like the one you're describing, so we support setting this up.

I just need somebody from the Vivliostyle project to say "yes" to my request to create containers in the "vivlio" namespace. I'll create the GitHub project in the DITA Community organization unless there's a better place for me to create it.

We are happy to take your offer to maintain this, but we would prefer owning the namespace (and we'd prefer using the full "vivliostyle" name rather than just "vivlio"). How about hosting it in a repo under our organization and we give you access?

We also like to make sure to set this up in a way that avoids accidentally distributing old versions once new ones are out, but I'm sure we can figure out the specifics as we go along.

Cheers,

--

Florian RIVOAL

取締役、Chief Commercial Officer

Vivliostyle

To view this discussion on the web visit https://groups.google.com/d/msgid/vivliostyle/580e52b0-9fc6-4d44-9249-ce10eceedeba%40googlegroups.com.

[Eliot Kimber]

Having the git repo in a Vivliostyle-managed organization is to be preferred. Using "vivliostyle" as the namespace is fine.

The general container management workflow I'm using currently is:

1. Set up automated builds on the Docker Hub site. These react to new versions of the Dockerfile being committed to GitHub.

2. For each new release you have to take these actions:

1. On the master branch, update the Dockerfile to reflect the new version (e.g., get the new release's installation package)

2. Set up a new automated build item to build a version-specific container (that is, a container tagged with the version number) by looking for a branch whose name is the version number. This takes about 2 minutes.

3. Create the new branch, branching from head

4. Push master and the new version-specific branches to GitHub to trigger building the containers on Docker Hub

Once this is done any subsequent pulls of the image with tag "latest" (which is the default tag) will get the latest version. 

This process could itself be automated but I haven't tried to do that yet in my Docker work. At some point it will probably be worth the effort.

My github ID is "drmacro".

Cheers,

Eliot