Docker
I've seen that a lot of projects and organisations are using Docker now. Containerisation in Linux has been around since 2008 in the form of LXC, but it wasn't until Docker was released into the open source environment in March 2013 that it's been a generally accessible and understandable enough concept to start gaining widespread use.
Contents
Organic design work-flow
Docker can make Organic Design's day-to-day work a lot more efficient in a number of key areas:
Server: The most obvious is to have Docker images for all the main components of the server such as code, web, mail, IRC, blockchain etc which would allow for a very quick server installation or migration process. It would also make it much simpler to work on the site locally to refine the image or work on configuration changes etc.
Clients: Each client or project should also have it's own Docker container so that it's easy to work on their system locally and offline. Each client system should include both server and client aspects so that the image can make team development better and also make the server environment more portable and reproducible.
Relation to the Organic Design vision
It's only recently (as of April 2016) that Sven mentioned that it's really important and that I should know about it and incorporate it into our processes. So I started looking in to it, and it quickly got me thinking about how it might apply to the Organic Design vision statement:
 | Our vision is to see all of our world's inhabitants governing ourselves with an open, accessible and understandable global system which has as its bottom line the common good, and which we define and operate ourselves by effectively utilising and allocating our common expertise and resource. |
Containerisation as a simple to use component is an important piece to the ultimate puzzle of how we at Organic Design could implement a system that supports this vision. For example, containerisation offers a means for implementing self containment and All aspects changeable which are core values for the Organic Design project.
The core values of openness and completeness refer to the fact that every facet of our reality and how we relate to it is covered by this system, and that state is available to all and made as understandable as possible. Of course that doesn't mean that nothing is private, this just refers to the ways we go about things, not to the personal details being managed in these ways.
The core value of "all aspects changeable" is that any part of the system, including the system environment itself, is able to be developed on by the community. An important part of being able to understand and change things is to be able to have an exact copy of the thing locally that you can use and experiment with, and Linux containers allow us to do this. Within this context is the core value of "think global, act local" is a general guide line to keep the system generally evolving in a selfless way that has the common good as its bottom line.
Of course containers aren't the whole picture, for the system to be truly open and transparent we must "own" it ourselves, which is where peer-to-peer comes in. And to be truly independent we must be able to maintain and own our identities, accounts and reputations together, which requires the best methods available for our privacy and security within this system. This requirement wasn't possible in a fully distributed environment until 2008 with Satoshi Nakamoto's proposed his solution to the "Byzantine generals" problem.
What we have here is quite a clear requirement: a peer-to-peer environment that we can log in to with our own distributed identity to access a network of public and private containers (i.e. complete environments) that we can collaborate on together. This network is formed by relationships where the basic geometry of relationships is defined to give a general class-instance relationship (i.e. what is an instance, or live copy, of what, and what implements what). We can see the combinations that others make for any aspect and have enough information to make informed decisions about how we'd like those things to be in our view.
One cool thing about this idea is that we don't need to define the ultimate set of components, we can just define any set of things that we know about and can get to work together. Once we have something functional, then its own collaborative nature can apply to every aspect of itself, so new ways of using it with better components will emerge and become dominant.
Initially in addition to Docker, I think I'd choose something like the InterPlanetary File System (IPFS) for the peer-to-peer storage layer with EncFS to encrypt private content and OneName] for authenticating users to unlock access to their content.
Things to refine/define
But what other aspects are required to pull this off and what options are their for those?
- Class/instance relation (including is_a and implements relations)
- Reporting on state including adjustable options (voting) and defaults (e.g. defer to group, majority etc)
Docker resources
- Dockerfile reference
- Understanding volumes in Docker
- Running an IPFS node in a Docker container and mount with Fuse
- Docker on Raspberry Pi - by Resin
- Docker in Raspberry Pi - by Hypriot
- rPi IPFS - Docker image for IPFS on Raspberrry Pi
