You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+17Lines changed: 17 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,6 +2,20 @@
2
2
3
3
This repo configures a set of services that PDX Hackerspace uses to provide services for its members and for infrastructure, administration and yes, fun and entertainment.
4
4
5
+
Hackstack uses Docker (with compose) to
6
+
7
+
Hackstack's priorities are:
8
+
- consistency - all applications follow similar conventions in how
9
+
they are configured, managed, store data and are backed up
10
+
- ease of management - Hackstack is meant to be manageable by users
11
+
with basic Linux knowledge and without advanced Docker or
12
+
virtualization environment experience
13
+
- low overhead - Hackstack is intended to minimize overhead when
14
+
possible - it should be possible to operate many Hackstack services
15
+
on small computers like a Raspberry Pi
16
+
- ease of recovery - Hackstack is designed to make disaster recovery
17
+
easy when possible
18
+
5
19
-[Philosphy and Design](docs/design.md)
6
20
-[Examples](docs/examples.md)
7
21
-[Installation](docs/installation.md)
@@ -12,5 +26,8 @@ This repo configures a set of services that PDX Hackerspace uses to provide serv
12
26
13
27
## Contributing
14
28
29
+
Please see the [Contributing](docs/contributing.md) guide.
Copy file name to clipboardExpand all lines: docs/contributing.md
+24-2Lines changed: 24 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,9 +6,31 @@ We don't intend it as any kind of ubiquitous or universal guide to server softwa
6
6
7
7
Hackstack applications all follow a set of conventions that dictate how they store data, publish network ports, use databases, are configured and backed up, and interact with one another. By following conventions the system stays manageable and organized; we know where everything lives and how it works, instead of being a haphazard collection of Docker and compose files that all do everything differently.
8
8
9
+
## tldr;
10
+
11
+
1. All applications have their own Docker Compose files
12
+
13
+
2. Each application lives in a directory in `/opt/docker`
14
+
15
+
3. Each application's volumes are filesystem binds that are stored in a directory named for the application `/opt/lib`, `/opt/logs` or `/opt/run`
16
+
17
+
4. Unless absolutely necessary, applications do not use host networking and do not publish ports. Whenever possible, applications are exposed via `nginx-proxy-manager`
18
+
19
+
5. Applications are isolated on Docker networks that connect functional groups
20
+
21
+
6. Unless absolutely necessary, applications use the shared instances of Postgresql and Mariadb and do not spin up their own instances of them. However, applications that require Redis do use their own instance of that.
22
+
23
+
7. Environment variables are stored in `.env`, not in `docker-compose.yml`. Applications should provide a `.env.example` with secrets redacted.
24
+
25
+
8. The environment variable `BACKUP_DATABASE_URLS` in a `.env` file will allow dumps of live databases to be backed up automatically.
26
+
27
+
9. Applications will be automatically updated by Watchtower. For locally built applications or applications that shouldn't be updated, add the label `com.centurylinklabs.watchtower.enable=false` to the compose file.
28
+
29
+
10. Applications that follow these conventions will have their files and databases backed up automatically.
30
+
9
31
## Docker Compose
10
32
11
-
All services are managed by Docker Compose. The service should include a docker-compose.yml file in a directory at the root of the repository.
33
+
All services are managed by Docker Compose. The service should include a `docker-compose.yml` file in a directory at the root of the repository.
12
34
13
35
As a rule we try to allow users to customize the installation as much as possible without modifying the compose file. Obviously this isn't always possible but we strongly prefer doing so when possible. This allows the user a change to potentially be able to simply pull new versions of the hackstack to gain new applications.
14
36
@@ -17,7 +39,7 @@ As a rule we try to allow users to customize the installation as much as possibl
17
39
Docker Compose can specify external directories or Docker volumes to be mounted inside the container. We use a specific organization for volumes (`APPNAME` is the name of the application):
18
40
19
41
- any configuration data will be stored in a directory called `config` in the directory containing the `docker-compose` file
20
-
- any runtime data, state information, sqlite3 databases - anything that maintains the state of the application and which must be preserved across runs - will be stored in `../../lib/APPNAME`. Applications which mingle configuration and run-time data in a way that makes it difficult to isolate them may store configuration data in this directory as well.
42
+
- any runtime data, state information, Sqlite3 databases - anything that maintains the state of the application and which must be preserved across runs - will be stored in `../../lib/APPNAME`. Applications which mingle configuration and run-time data in a way that makes it difficult to isolate them may store configuration data in this directory as well.
21
43
- log files go in `../../log/APPNAME`
22
44
- transient runtime files, like caches or FIFOs, go in `../../run/APPNAME`
0 commit comments