-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docker container fails to start failing to find coffee-script module #110
Comments
I wonder if it makes sense for this repo to even suggest one way to run wiki inside of docker. The docker ecosystem is much larger than our project and has developed its own standards and conventions. I would like to see various production ready configurations developed and containerized as separate projects. TLS is a good example of something looming over us for which there are many solutions. Login and persistence are two more variables. Backups and logging come to mind too. |
My background: My path from here: My issue: |
We are slowly moving toward more configuration being done from within wiki rather than by issuing shell commands before launch. There are a few things that must be known to make this work but these would be expected as environment variables as I understand is a docker best practice. One important environment variable would be the identity of the administrator who is granted configuration powers. I do not speak from experience here so consider this speculation. I can imagine at least three off the shelf docker configurations.
I would expect each of these to be available in docker image repositories and built from projects of their own with their own user communities. This could reasonably be part of the fedwiki github org but need not be. I would expect this org to maintain key repos, wiki, wiki-server, wiki-client, as required to support inclusion in docker builds downstream. This would be a separation between coding in javascript and administration with command line tools captured in docker files. I would not expect this org to be experts about the specific constraints of docker and the evolving best practices about working within them. We are interested, but not expert. |
Regarding coffeescript. I have a vague memory of installing this on my computer using instructions I found on the coffeescript site. It was something like
Perhaps someone watching will tell us the preferred approach. |
Found the issue:
That basically mounts the current host directory over the app directory from within the image as specified at build time. |
Regarding possible future docker images, I would recommend, as a user seeking straight forward components with a reasonable learning curve, not an expert, the following:
In my case, using a configuration mount and a data mount is enough to have my old welcome page and the owner set, so I have my old 'site' in docker now. 👍 Ideally, parameters should be exposed for any and all aspects of configuration and consistent precedence should be established (env vars > file config or the reverse) |
Well, you see that my advice is not of much value when it comes to docker. My own computers are insufficient to even start it. Do you think it possible that this configuration has ever run? |
The docker configuration here was added back in 2014, in d29177a, to "create reproducible development environments and scenarios". I am minded to simply remove the docker element from this repo, it has caused needless confusion on more than one occasion, and have a separate repo for docker. In fact several already exist, for example https://github.com/dobbs/wiki-tls . |
@Andrei-Paul, the docker ecosystem has definitely exploded in the past 4 years. There are a lot of lessons that have been learned since these first steps were taken in fedwiki/wiki. I have been building https://github.com/dobbs/wiki-tls (as @paul90 already pointed to) with the benefit of more recent docker experience. That's got fairly recent docs in wiki over here: https://local-farm.wiki.dbbs.co I use the same code with different In @WardCunningham's categorization this thing is in-between the first two bullets:
It is bigger than a single wiki. It is a wiki farm. It includes a reverse proxy and TLS. But it is built for a single author and lacks tooling for supporting a community. I'm gradually building roads toward more complete path to production, some of which will find their way into our "official" docs soon. |
|
@paul90 I would second your idea to remove any docker specifics from the repository. Indeed it is at times convenient, if developers provide Dockerfiles to their projects for development. Yet these are also often mistaken for production ready environments, which they are not. The diversity in Docker-based environments, starting with plain Docker, moving past docker-compose and looking at hybrids that build and orchestrate such containers, as CI/CD pipelines or "PaaS" like Dokku, allows us to anticipate the diverse set of requirements we are facing here. Together with the perceived user bases, we may give in and not support this at all in the core. Coming from here the community could coordinate around increasing documentation around how to set up a build environment for development or production cases and provide exemplary configurations for those, given different user groups needs (proxy, or not, farm, or not, transporters, or not, customised security, or not, plugins, or not, ...). As an example, the Dokku application which receives https://github.com/federated-wiki/dokku-wiki-distribution/blob/master/Dockerfile is configured to pass a selection of wildcard domains in nginx' special This setup itself is based on a choice of plugins https://github.com/federated-wiki/docker-wiki-distribution/blob/master/Dockerfile, which are provided to extend an assumed standard way of setting up a wiki core https://github.com/federated-wiki/docker-wiki-core/blob/master/Dockerfile @Andrei-Paul If you are comfortable with maintaining build pipelines and image maintenance, I would like to invite you to collaborate on reproducible and documented example wiki configurations for development and production use. These cases could both target Dokku and Docker-Compose as platforms each. The core and distribution from above surface as automatically built images, syncing to the tags of the source repositories, at https://hub.docker.com/r/federatedwiki/base/ and https://hub.docker.com/r/federatedwiki/distribution/tags/ |
Discussion in fedwiki#110: we prefer to move docker suggestions outside of the main repo to open way for describing many configurations.
Steps to reproduce:
Expected Result:
Have a container of wiki_web image running.
Actual result:
Container exited. Logs:
Additional information:
I receive the following during the build process:
The text was updated successfully, but these errors were encountered: