search

libresh / applications

Applications we offer
9 stars 5 forks source link

Move discourse, libreboard and etherpad to IndieHosters repo #52

Closed pierreozoux closed 9 years ago

pierreozoux commented 9 years ago

Yep!

What do you think of moving these 3 apps to IndieHosters repo? https://github.com/IndiePaaS

I prefer to have each app on a separate repo, then it is really easy to keep track of everything. It's really modular this way. We could have then one repo, like this one, that have them all as git submodules.

If you like these 3 images and are ready to merge them into IndieHosters app, and ready to offer them to your clients as well, then, I'll start to rewrite the other apps to fit this "standard" nad move them little by little to this repo.

For me this is the best plan.

What do you think?

michielbdejong commented 9 years ago

I'm using https://registry.hub.docker.com/repos/indiehosters/ and https://github.com/indiehosters/applications in production so if any of the existing apps change, either in the Docker registry or in that github repo, we need to coordinate.

Other than that, I don't have a strong opinion about one repo vs. one repo with submodules vs. multiple repos. But I do think we should still merge our application collections.

What would it take to add those three applications to https://github.com/indiehosters/applications/tree/master/services?

pierreozoux commented 9 years ago

Yes, we need to merge it, this we agreed on :)

I like the one repo approach with submodules. If you don't have opinions, then, let's go for that.

I don't want to add these to applications, as they are a bit different. There are no dockerfiles. The idea is to have a START, STOP, BACKUP and maybe BUILD script, and you just need to execute them from the user's folder, and it's done. I cn execute them from Systemd, you could do it from snickers, or tomorrow , it could be odoo... It's really flexible in the mean time we have a decision about the scheduler.

This is my idea of standardisation, these little bash script. We shouldn't look into them, we just run it, and it's done.

The BACKUP script is the same. It's not IndiePaaS specific.

The discourse is just that discourse is a bit specific, so I just use the way they are doing stuff :) And the START and BUILD scripts are abstractions. And yes, for each domain, then I change manually he sample.yml and use the BUILD script to ahve the docker images needed.

Let's say these 3 images is just a proof of concept of what could be a common application. That you could use and I could use, and also somebody else could use easily. If you like the way it is done then we can start from there, and migrate the "legacy" to this format.

This is just a proposition to start the conversation :) And as we respect IndieWeb principles, I just start to host them ;)

best!

michielbdejong commented 9 years ago

Hm, so the idea of having 'START', 'STOP', and 'BACKUP' bash scripts is of course very flexible, but if we switch from Dockerfiles to that, then we need to document:

I think the real problem doesn't lie in the choice between Dockerfiles or unit files or bash files. Bash is a nice choice, though, as it is quite universal. However, I think it's easy to install an application on a server, but harder to configure it to do exactly what you want when you run it, and what I want when I run it.

pierreozoux commented 9 years ago

System requirements:

File path

Why not stick to /data/domains ?

host application?

I would say no. But if in the future, some app dev prefer to ship their app on rkt or systemd containers, I wouldn't mind. It has to be well isolated. And the container is our choice of techno. Then, it's up to the app dev to choose their techno.

SNI

Yes, only SNI.

ENV Var

This is still not solved by these 3 apps experiment. I think I could guess the domain name from the folder. I think we could put the admin email and email server conf in env var. To be discussed/solved.

Runtime environment

I choosed bash as a temporary solution, because docker doesn't offer anything to describe runtime environment. Maybe it is not the best choice, it is one choice :)

Nothing is in stone, it is here to be commented and improved. Tell me what kind of limitations you see?

From my point of view, the great news is that, I didn't write any docker file for any of these apps :) I just reuse the work of app dev, or the community. And this is awesome!

michielbdejong commented 9 years ago

docker doesn't offer anything to describe runtime environment.

docker-compose lets you define env vars and volumes, doesn't it? I think the only thing it doesn't allow is to add predefined exec commands like your backup command.

but even then, an application is defined by a template of a docker-compose file, where you can fill in things like domain name and mail server IP address, which depend on the installation and not on the packaged app.

maybe just the BUILD and BACKUP script should be different for each app, and the START and STOP script can then be the same for each app (especially the STOP script does not seem to have anything application-specific).

pierreozoux commented 9 years ago

Yes, this is true, docker doesn't but docker-compose does :)

About the START script, I don't know what to answer. I guess, I understand your point of view, you want to continue to develop snickers, and this is the only way to do so. From my point of view, I prefer a START script, just because I don't know what will be the standard tomorrow. For instance, discourse didn't adopt a docker-compose approach, and so we'll have to make specific dev for that happening (maybe in he future they will).

As there is just one app like this for now (discourse), let's say we take the decision to use docker-compose. It means we'll migrate existing app to this. Is it fine for you?

Actually, the START script is called RUN right now, but I think you are right, it feels more natural to call it START.

One more think. I know you prefer to have just one image with everything inside. As you see, I just reused images from docker registry, and/or projects, so if you want this, I think you'll have to develop it yourself, and pull request to the repo? I just think it is better to use what exists.

michielbdejong commented 9 years ago

stopping and starting the right containers becomes a bit more difficult if there are multiple containers, they are likely to take longer to start up, and maybe they will use more memory. but the ability to use upstream images (which often rely on a separate database container) is a more important argument, and also once you have docker-compose it would feel unnatural to not allow multiple containers in there.

in the case of discourse we would just have to write a build script in bash, that produces a docker-compose file, i think. This could be the approach for all apps, to take care of templating of instance-specific environment variables that need to go into the docker-compose file.

it's not by itself a problem to execute a bash script instead of doing a Docker api call whenever snickers wants to create, start, or stop a container. in fact, switching snickers from dockerode to bash execution would probably be easier than handling the docker-compose files in nodejs.

it's just that, unlike the BACKUP and BUILD scripts, the RUN/START and STOP scripts seem to be an unnecessary wrapper around docker-compose.

so maybe the nicest solution is:

add a new domain -> execute a bash script to create the right folders and the docker-compose file tell a container to back up its db -> execute a bash script that does some docker exec-like thing start a container -> use the standard docker-compose way stop a container -> use the standard docker-compose way

michielbdejong commented 9 years ago

so then it's a combination of bash and docker-compose.

pierreozoux commented 9 years ago

Ok. agreed, we need a better BUILD script :)

For the RUN and STOP, I'll just keep them for now, as I still use them. But with plan to remove them. For the discourse, I can't migrate it to this repo then. If somebody has time one day, it would be cool to be migrated to docker-compose. In the mean time, I'll just keep it on my repo as it is.

So, if you agree, I migrate etherpad and libreboard as submodule in this repo. Then, we'll have to build better BUILD script. But they are already usable even without the BUILD script.

Just as a side disucssion, I have this script to create a dir, buy a domain name, create the CSR. I plan then to interface it with the BUILD script. But this is another discussion.

pierreozoux commented 9 years ago

actually, the BUILD name collide with the concept of build in docker world (in the case of discourse, it is the case). Maybe FIRST_RUN would be more appropriate. I have troubles naming things :/

michielbdejong commented 9 years ago

'configure', maybe?

pierreozoux commented 9 years ago

Sounds good!

pierreozoux commented 9 years ago

So I moved the following:

I still have to move:

Do you plan to use the ownCloud soon? Then if you have feedback, I can apply it to the next.

pierreozoux commented 9 years ago

Ok, As discussed, RUN and STOP are not necessary.

Configuration will be part of the docker-entrypoint script.

Backup will be made this way: https://github.com/docker/compose/issues/1748 with a backup container.

Any opinion?

Then the standard of IndieHosters application is just whatever docker-compose file.

pierreozoux commented 9 years ago

Ok, I created an issue for Libreboard, etherpad and discourse.