OuiShare

Compost
1

Continuing the discussion from Root server sharing under supervision of Ecobytes?:

Meanwhile some more requirements came in via another channel:

labs drupal needs to move asap because daniel wants to kill the server it’s on; + other little things (wordpresses, knowns 2+ at once, a wiki, and can docker make just ftp slots/folders as well? i’ll clear the requirements for that)

Let’s use this thread for coordinating OuiShare’s needs. Before we can deploy your VM, we will need an SSH key from authorized persons to access the machine.

2

yo!

I sent you my key by mail.

Once you get the server, I can install IndiePaaS. Or if you prefer, you (@Auli or @almereyda) install it with instructions (There are none for now, but I have to do this work anyway). Then, I can explain you how to provision one website in 5 minutes (like by making documentation, and answering for support).

I don’t know if it is the plan you though, but this is the plan that I though is good (for me :)).

And then, we can iterate from there.

What do you think?

3

I think the iterative mode is good for progressing. While we’re at it, we could think about using a taiga/trello/… workflow for aligning documentation and activities. Therefore @auli’s mails and :page_facing_up: my notes in StackEdit (only accessible publicly with this link or manually via adding the OuiShare Labs Tag to the (kind of broken) Open from CouchDB dialogue) can converge within the process to valuable reports.

Please allow me the good weekend to get the infrastructure running.

@gualter Do we have a small oneliner which can tell me how much RAM we provisioned (soft & hard) within virsh? To scale the OuiShare machine properly. I’m thinking of something like

virsh list | xargs virsh dumpxml | grep memory
4

Here’s a new Ecobytes-specific doc about OuiShare further clarified needs >>

As agreed, let’s start with minimal efforts for now and move on as resources emerge.
The start could include a WP farm and GitLab setup, having in mind all the other tools and purposes that we’d like to build out over time (listed in the doc).

I’m happy to help and commandline if you tell me how :smile:
re: weekends: available 6-7 and 20-21 June, offline 12-14 June.

5

I can host LibreBoard since last week :slight_smile: Would be happy to do so for our project!

1 „Gefällt mir“
6

I consider it ugly and it uses MongoDB; but why not ^_^.

7

Here it is: https://libreboard.tokoloho.co/boards/Ash5sEnwHApM7tPZJ/indiehosting-ouishare-at-ecobytes (I own tokoloho.co, tokoloho means freedom in sesotho :slight_smile: If you prefer another domain name, thanks to let me know)

8

We can provide access to Ouishare to our Drupal farm as soon as you need to start migration. Deploying further ones, if needed to scale, is also easily done, but could benefit from engaging someone from OuiShare (or other collective) in managing the Drupal BOA (Barracuda-Octopus-Aegir) servers stack.

We have also recently a new Wordpress server deployment which generates new multiserver Wordpress farms with one command. @asdx has been working on it and my tests in the last month show a very high performance and stability.

So if you have some contact person for each of these platforms on your side - ideally with time to collaborate -, we could work on providing you the infrastructure for your migration very soon.

9

@auli @pierreozoux You should now both have access to 5.9.161.182. Only key-based login is enabled, but for sudo you’ll need to change your passwords changeme first with passwd after successfully logging in with your users kirilind or pierre.

Please tell me if this worked. It’s a 1-2GB 2vCore machine.

Then as a first try I would like to migrate a backup from http://discourse.ouishare.net to the IndieHoster’s template.

Also, I think playing with https://rancher.io makes sense in a broader IndieHosters federation at Ecobytes. Especially helping them with developing their ACL part could help us a lot @pierreozoux @gualter.

Let’s roll it!

1 „Gefällt mir“
10

Cool stuff. https://rancher.io seems to be down though, so I can’t even start to think about what you are asking :wink:

Would you be willing to write some documentation about the Discourse farm, ideally with a step-by-step guide on how a member of the federation (?) can quickly deploy its own instance?

Perspectively, such services (Discourse, Drupal, Wordpress, …) should be available with a few clicks.

11

Check out http://rancher.com/rancher-io/ then. Sorry for mixing the product name with the FQDN.

This will now preferably be within the IndiePaaS framework.

@pierreozoux, what do you think, can Rancher help us getting closer to self-deployment? I mean, if it has an API, we could just write a simple frontend module which provisions selected containers, no? I mean, Docker itself is basically just an API, too.

12

Well, then please document or create a link a description of the IndiePaaS framework. We need to make the access to what it means and how to use transparent and intuitive to all members/customers of the different collectives in the federation.

13

Part of the reasoning why we, @auli, @pierreozoux and me, intend to run IndiePaaS and other services for OuiShare, as their maintenance involvement is initially not meant to be on the command line :wink: , is exactly to improve the overall situation for all possible communities in using these advanced infrastructures.

Within this collaboration https://github.com/indiehosters/indiehosters can grow to something more usable. Also see

1 „Gefällt mir“
14

Sorry, I didn’t have time :confused:

The future

About rancher.io or it’s alternatives. I still don’t know what to say… The alternatives are listed here. And every weeks, there is a new one. To complete the list, I think clouder is an interesting alternative also.

The issue with these things, is that they all have some kind of limitations. And basically they are built for modern services, like node or mongo, but not for old services like postfix or wordpress. And also, they are a bit reinventig the wheel like load-balancing or DNS which introduce limitations. That’s why I started IndiePaaS, to be free! And also to learn while doing things :smile: I have to admit, I really enjoy the learning part!

For now, it is mostly administered though bash scripts. There are some automation made with etcd, like config for HAproxy. I would say that it takes me around 20min to setup a new web app for a user.

IndieHosters way

As I see it, and as discussed with @michielbdejong, for now we have a different infra. We are now focusing on merging our web app to have the same list, and work together on maintaning those. See this discussion.

The next pass would be to choose an orchestration framework. If we can’t find one that fits our need, then we’ll take either IndiePaaS or snickers. (Personally, there are some issues that scare me a bit)

And then we would interface an ERP like odoo to the choosen orchestration framwork. At this time, any body, even non tech would be able to administer a hosting service provider by using this ERP.

As you can see, we, at IndieHosters, are also on this direction.

Then, the pragmatic part - collab between OuiShare - IndieHosters - Ecobytes

I think packaging application together is a great win! Maybe goclouder will reuse our work, would be amazing!

If you want I can help you setup IndiePaaS. On the readme there is instruction to start a test server. It is not really different from setting up a prod server. I know it is not perfect, and there is probably a lack of some stuff, but should be good enough to start. You can come at the IndieHosters IRC channel, and we could do a live “installing” session / improving documentation. (I’m a bit running out of time for June…)

If you prefer, I could setup an instance IndiePaaS on this server. And provide instructions on how to run the discourse instance.

As I see it, if I do it, it will be quick, but nobody will learn anything. If you (@auli or @almereyda) do it, it will be slower, but it will be a great way to learn together and improve the doc. I can be here, and respond to any question at any moment (Though GitHub, IRC or email)!

Please let me know!

Best!

Pierre

15

@auli needs something to show by wednesday, 24th of June. I’m back from TransforMap only at the beginning of next week, so Monday and Tuesday.

Let’s try to pre-plan them and find suitable hours.

16

@pierreozoux @almereyda Rancher looks interesting, do I get it right that it enables cross-server app management/overview? As does clouder? (Would that mean that we could eventually join the information on the apps we have on webfaction server to this whole thing, plus our AWS account that hosts some images for ouishare.net? Or is this not practical?)

What about the idea of having several app overview softs and running them side by side (for testing and documenting)?

Otherwise I don’t have a strong preference, at first the thing (dockers?) could also run with bash scripts if we document briefly for dummies (like me) how they’re supposed to be managed, how to create a new web app etc.

yay for testing with OuiShare discourse : we might find it usable for some projects+discussions documentation soon. (soon = by end of summer)

I’m available for coworking next week, Monday better.

17

I’ll be available Monday and Tuesday on IRC if needed with little time (have to finish docker training :confused: )

I think we can already present stuff like: https://stream.ouisharelabs.net/ and discourse even if not merged on new server. (It doesn’t matter much if the server is x or y).

@auli yes, we could try all of them, there is actually 2 issues to be solved here. Feel free to solve them :slight_smile: I’d love to have time to solve them also actually!

Let’s start with installing IndiePaaS then, and try to migrate discourse. I think it would make more sense if @almereyda is installing IndiePaaS, and then @Auli would install the disourse part. It is partly bash scripts, and it is not that difficult.

I just wrote a blog post to document a bit, but would be great to make a better documentation!

https://microblog.pierre-o.fr/2015/how-indiepaas-work-in-the-big-lines-and-futur-of

18

Migrating Discourse isn’t too hard. The internal backup function works quite well already. The last time I checked the IndiePaaS approach to Discourse didn’t use multiple containers for Redis, PostgreSQL and the Web Frontend. Also I’m not sure how you’re injecting plugins. The Discourse Launcher is actually quite good.

Nevertheless, @pierreozoux and @gualter you have access to https://federated.cc (handle with care) Where I’m playing with Rancher, if you wanted to add some nodes or play with it in general. I’ve even managed to upgrade Docker under the hood of Dokku-alt, despite the Debian packages haven’t been upgraded for the changing lxc-docker > docker-engine dependency. dpkg -i --ignore-depends=lxc-docker dokku-alt-beta-0.3.10-146-g1ee5f7c-amd64.deb helped out. After you login you will see it’s quite a weird setup, but I’m learning continuously.

GitLab has to be updated and finally working.
Deis wants to replace Dokku.
The machine running Rancher uses the nice dockergen nginx proxy.
Everything is more and more automated.

I’m happy.

19

Nice :smile:

Isn’t it dead this project?

I don’t have much time right now (have to update IH website for french coming :smile: https://framadrive.org/ before the 6th of October :confused: ) But yeah, after that, I’d love a little presentation live maybe - with screen sharing? What do you think @gualter?

Happy that you are happy!

20

Didn’t have the feeling lately, but I may be totally wrong. https://github.com/rancher/cattle/graphs/contributors looks quite continuous. Which interface would you favour for community-supported clusters?

The good thing with (boycott?) docker is how its parts are interchangeable and composable. With libnetwork and storage plugins on the horizon lovely as hell. Why not run a ceph docker (OpenStack/Synnefo block and object storage compatible) for the local docker-registry? Itself being stored on a cluster?

Also nice to see Frama ever expanding and active collaborations taking place.

Ecobytes is still kind of occupied with running the legacy stacks, not much time for containerization of the states hidden in the backups.