moving everything to active or retired vs incubating and graduated
All checks were successful
Reese's Arch Toolbox / build-and-push-arch-toolbox (push) Successful in 14s
All checks were successful
Reese's Arch Toolbox / build-and-push-arch-toolbox (push) Successful in 14s
This commit is contained in:
126
README.md
126
README.md
@@ -4,9 +4,10 @@ A project to store homelab stuff.
|
||||
|
||||
Just here for the Arch distoolbox?
|
||||
|
||||
[Arch Distoolbox](infrastructure/graduated/distoolbox/distoolbox.md)
|
||||
[Arch Distoolbox](active/software_distoolbox/distoolbox.md)
|
||||
|
||||

|
||||

|
||||
|
||||
## Table of Contents
|
||||
|
||||
@@ -15,16 +16,18 @@ Just here for the Arch distoolbox?
|
||||
- [Fun Facts](#fun-facts)
|
||||
- [Important Dates and Times](#important-dates-and-times)
|
||||
- [Project Lifecycle](#project-lifecycle)
|
||||
- [Supported Projects](#supported-projects)
|
||||
- [Graduation Requirements](#graduation-requirements)
|
||||
- [Project Types](#project-types)
|
||||
- [Active Project Requirements](#active-project-requirements)
|
||||
- [Retirement Requirements](#retirement-requirements)
|
||||
- [Project Structure](#project-structure)
|
||||
- [Creating a Project](#creating-a-project)
|
||||
- [Order of Operations](#order-of-operations)
|
||||
|
||||
## Fun Facts
|
||||
|
||||
On linux, <kbd>ctrl</kbd>+<kbd>shift</kbd>+<kbd>u</kbd>, then, while holding
|
||||
<kbd>ctrl</kbd>+<kbd>shift</kbd>, typing <kbd>b</kbd>+<kbd>0</kbd> will type a ° (degree) symbol. Also you
|
||||
can enter any unicode symbol this way.
|
||||
<kbd>ctrl</kbd>+<kbd>shift</kbd>, typing <kbd>b</kbd>+<kbd>0</kbd> will type a
|
||||
° (degree) symbol. Also you can enter any unicode symbol this way.
|
||||
|
||||
## Important Dates and Times
|
||||
|
||||
@@ -34,55 +37,67 @@ can enter any unicode symbol this way.
|
||||
|
||||
## Project Lifecycle
|
||||
|
||||
Projects will fall into one of the three following categories:
|
||||
Projects will either be `active` or `retired`.
|
||||
|
||||
1. Incubating
|
||||
2. Graduated
|
||||
3. Retired
|
||||
Active projects are being actively developed. They are in-use, stable, and
|
||||
production ready. Active projects should meet and track the [active project
|
||||
requirements](#active-project-requirements)
|
||||
|
||||
Incubating projects are experimental or prototypal. They're being actively developed and aren't
|
||||
ready for production deployment. These projects may appear and disappear without warning and are not
|
||||
stable. There is no minimum requirement for a project to be in incubation.
|
||||
Retired projects are no longer in use or recommended. They are kept for
|
||||
reference. Retired projects must meet the [retirement
|
||||
requirements](#retirement-requirements)
|
||||
|
||||
Graduated projects are in-use, stable, and production ready. They met the [graduation
|
||||
requirements](#graduation-requirements) and are actively maintained.
|
||||
You'll notice that most of the active projects have scripts or examples that
|
||||
use the `active` path as part of their install process. When moved outside the
|
||||
`active` directory their scripts and examples break. This is intentional. If
|
||||
you want a retired project to work again, bring it back to the active
|
||||
directory.
|
||||
|
||||
Retired projects are no longer in use or recommended. They are kept for reference. Retired projects
|
||||
must meet the [retirement requirements](#retirement-requirements)
|
||||
## Project Types
|
||||
|
||||
## Supported Projects
|
||||
All projects will be prefixed with one of the following categories:
|
||||
|
||||
All projects will fall into one of the following categories:
|
||||
- `device_`
|
||||
- `os_`
|
||||
- `cloud_`
|
||||
- `systemd_`
|
||||
- `podman_`
|
||||
- `docker_`
|
||||
- `kubernetes_`
|
||||
|
||||
- hardware
|
||||
- infrastructure
|
||||
- cloud
|
||||
- systemd
|
||||
- podman
|
||||
- docker
|
||||
- kubernetes
|
||||
Note, some projects will be named with just the prefix. These are projects for
|
||||
configuring the underlying technology. The `podman` project, for example, will
|
||||
tell you how to configure and install podman so it works correctly.
|
||||
|
||||
Hardware will contain projects that relate to specific machines or equipment. 3D printers, Raspberry
|
||||
Pis, and other IOT devices qualify as specialized hardware that needs documentation and
|
||||
configuration. This is not limited to computer equipment. The furnace is an important part of the
|
||||
home lab. the Air Conditioner is integral to the homelab's function. These projects will also be documented.
|
||||
`device_` will prefix projects that relate to specific machines or equipment.
|
||||
3D printers, Raspberry Pis, and other IOT devices qualify as specialized
|
||||
hardware that needs documentation and configuration. This is not limited to
|
||||
computer equipment. The furnace is an important part of the homelab. the Air
|
||||
Conditioner is integral to the homelab's function. These projects will also be
|
||||
documented.
|
||||
|
||||
Infrastructure will contain projects that set up the environments for the remaining listed project
|
||||
types. For example, infrastructure will contain "how to set up a linux box with docker" or "how to
|
||||
set up a k3s cluster for kubernetes".
|
||||
`os_` will contain projects that set up operating systems. These include best
|
||||
practices, backups, updates, default software, etc.
|
||||
|
||||
Cloud projects are for specific cloud providers.
|
||||
`cloud_` projects are for specific cloud providers. This will contain
|
||||
documentation and errata for things like AWS IAM, Route53, etc. Note these will
|
||||
be prefixed with the cloud's name, not the word "cloud". So AWS services will
|
||||
be prefixed with `aws_` and azure would be `azure_`. This should make them more
|
||||
searchable.
|
||||
|
||||
Systemd projects are designed to be installed with ansible and run via systemd on a linux VM or
|
||||
other linux hardware.
|
||||
`systemd_` projects are designed to be installed with ansible and run via
|
||||
systemd on a linux VM or other linux hardware.
|
||||
|
||||
Podman projects are either designed to be run as quadlets or as podman containers outright.
|
||||
`podman_` projects are either designed to be run as quadlets or as podman
|
||||
containers outright.
|
||||
|
||||
Docker projects are either docker-compose or some form of docker run command.
|
||||
`docker_` projects are either docker-compose or some form of docker run
|
||||
command.
|
||||
|
||||
Kubernetes projects are helm, kustomize, kubectl, or some other kubernetes compliant deployment.
|
||||
`kubernetes_` projects are helm, kustomize, kubectl, or some other kubernetes
|
||||
compliant deployment.
|
||||
|
||||
## Graduation Requirements
|
||||
## Active Project Requirements
|
||||
|
||||
- [ ] Installation is documented
|
||||
- [ ] Installation configuration examples are provided
|
||||
@@ -98,11 +113,30 @@ Kubernetes projects are helm, kustomize, kubectl, or some other kubernetes compl
|
||||
- [ ] If applicable, a replacement has been identified and documented
|
||||
- [ ] If applicable, backup data locations are documented
|
||||
|
||||
## Project Structure
|
||||
|
||||
All projects will have, at minimum.
|
||||
|
||||
1. A README named `project-name.md`
|
||||
2. A directory called `secrets` which will be gitignored.
|
||||
|
||||
## Creating a Project
|
||||
|
||||
Assuming your project name is `my-project` and it runs on `podman`
|
||||
|
||||
1. Create a new directory called `podman_my-project` under the `active`
|
||||
directory
|
||||
2. Copy the readme template: `cp project_readme_template.md
|
||||
active/podman_my-project/my-project.md`
|
||||
3. Populate `my-project.md` as you work through the install process
|
||||
4. Create a directory called `secrets` in `podman_my-project`. This will be
|
||||
automatically gitignored. Put all secrets here.
|
||||
5. Push the changes when you have a working product
|
||||
|
||||
## Order of Operations
|
||||
|
||||
1. Install cloud projects. These usually have no dependencies and typically provide critical services
|
||||
to other projects (DNS, email notifications, etc.)
|
||||
2. Install infrastructure projects. Usually these only have dependencies on cloud services.
|
||||
3. Install systemd services. These are usually low-level programs that require a dedicated machine
|
||||
and perform semi-critical functions (ipv4 proxy, ddns, etc.).
|
||||
4. Install kubernetes, docker, podman, and other services.
|
||||
1. Configure cloud providers. These usually have no dependencies and typically
|
||||
provide critical services to other projects (DNS, email notifications, etc.)
|
||||
2. Install infrastructure projects. Usually these only have dependencies on
|
||||
cloud services.
|
||||
3. Install systemd, kubernetes, docker, podman, and other services.
|
||||
|
||||
Reference in New Issue
Block a user