Docker Container with minimal install

[cfedermann]

S/N: 23
Priority: Low
Title: Docker Container with minimal install
Proposer: Nitin Madnani
Notes: In progress

[CTNLP]

I was under the impression this was done now. Should this issue still be open?

[villalbamartin]

I'm not exactly sure where does our Docker Container fall in the overall plans of the Anthology. There is a container, true, but for true support it should be

• ... available in Docker Hub and automatically updated (harder than it looks, based on last time I tried)
• ... published... somewhere? I don't really know who is using it, so I don't know how they would find out about it
• ... promoted as part of our "plan of mirrors" that Create a plan for mirrors. #28 mentioned

Then again, if we are changing the Anthology the whole project might be moot anyway. I'll link to this ticket on the migration project for future reference, and otherwise I'm not opposed to closing it.

[knmnyn]

#28 was from when I was taking charge of the Anthology. I think @mjpost has a different prioritization for Docker support and its use for mirroring.

[mjpost]

My impression was this was mostly needed for managing the dependency chain for the Rails app, right? Or were there further uses planned for it?

[knmnyn]

Hi Matt, all: You're right it was originally for the difficult problem of the setup of the Anthology app. We had also envisioned having a network of Anthology mirrors so that we can distribute the materials and not have a single point of failure.

…

On Wed, Feb 13, 2019 at 10:11 AM Matt Post ***@***.***> wrote: My impression was this was mostly needed for managing the dependency chain for the Rails app, right? Or were there further uses planned for it? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#22 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANP63nCbHz2HLJlpPikGZrsI8iOBZfeks5vM3Q9gaJpZM4J5OCa> .

[mbollmann]

With the static rewrite, the required dependencies for generating the site will probably be much more manageable. What's more, we can probably just offer an archive of the fully generated site as a source for mirroring.

However, static rewrite doesn't mean we can't have any server-side components at all, like scripts getting called or database interaction. I'm not yet sure to what extent this will be needed.

[mjpost]

My vision here is that the hosting server will pull from the repo each night and regenerate the site, in an entirely automated fashion. We could easily make available a Docker container to do that if there were interest in hosting local mirrors.

The issue with mirroring entirely is that the entire site (with all PDFs) is about 35 GB. Not monstrous, but not small, either.

[mbollmann]

FWIW, the entire site without the PDFs and attachments is at 112 MB (compressed) now.

However, full mirroring including the PDFs and attachments is not as trivial as pull & build, since the URLs for those are hardcoded in bin/anthology/data.py. I would need to make those relative or configurable somehow before full mirroring is possible.

[mjpost]

Yes, right. I think this issue is a low priority.

[akoehn]

We currently don't need a docker container and I see no reason why this should change in the future. The relevant aspects of mirroring are better discussed in other issues such as #295.