Page MenuHomePhorge
Files F117756667

No OneTemporary
Actions

Authored By
Unknown
Size
6 KB
Referenced Files
None
Subscribers
None

View Options

diff --git a/docs/docs/overview/containerization.md b/docs/docs/overview/containerization.md
index afdf25d..14a0e2f 100644
--- a/docs/docs/overview/containerization.md
+++ b/docs/docs/overview/containerization.md
@@ -1,32 +1,35 @@
-# Why Kolab is containerized
+# Containerization & Kubernetes
+
+## Why Kolab is containerized
Kolab's components are packaged and distributed as OCI containers that can be run via various tools such as podman, docker or kubernetes.
Containers address a couple of concerns:
-Kolab consists of a set of existing open source components, such as cyrus-imap and postfix. While Kolab technically can be made to work with alternatives, such as Dovecot IMAP instead of cyrus-imap, this results in essentially a new product with it's own set of issues and needs to be developed/validated/managed accordingly. It is therefore benefical to have exactly one defined software configuration of each component.
+Kolab consists of a set of existing open source components, such as cyrus-imap and postfix. While Kolab technically can be made to work with alternatives, such as Dovecot IMAP instead of cyrus-imap, this results in essentially a new product with it's own set of issues and needs to be developed/validated/managed accordingly. It is therefore beneficial to have exactly one defined software configuration of each component.
This ensures that we run what's being tested and that we take responsibility in what's included in Kolab, which is paramount to ensure environments are reliably reproducible, so that each installation doesn't have to be treated individually.
-Many of the components that Kolab uses have vast configuration options, allowing one to build entirely different things just based on configuration. When we talk about Postfix in Kolab for instance, we expect a specific configuration, and containers provide the means to ensure that all components run with the expected configuration.
+Many of the components that Kolab uses have a vast amount of configuration options, allowing one to build entirely different things just based on configuration. When we talk about Postfix in Kolab for instance, we expect a specific configuration, and containers provide the means to ensure that all components run with the expected configuration.
Another benefit of the container model is that we get a very clear separation for the "state". All state is written to mounted volumes in the containers, and the containers themselves are by definition ephemeral.
Finally, Kolab delivers a software solution that can be fully built from source, and containers provide a readily available build-system to build all components directly from source. This is a huge benefit in comparison to maintaining completely separate package building infrastructure for a variety of platforms, and provides Kolab with a great developer where all components are readily available to modify, build and distribute changes.
-# Why Kubernetes & Helm
+## Why Kubernetes & Helm
While containers provide great building blocks for the overall solution, it is ultimately required to orchestrate the execution of the various workloads in a defined configuration.
Kubernetes provides us with:
+
* A uniform model to orchestrate workloads on one or more nodes (servers).
* A communication plane for the individual workloads to communicate with each other.
* A solution to monitor and supervise the various workloads and to collect the logs.
* A declarative specification of the workloads to run.
* A uniform way to execute administrative tasks on the command line, that is independent from where the workload is running.
Kubernetes uses a verbose declarative specification to schedule the workloads, which is unwieldy to use directly, but lends itself to automation.
Helm provides us with a templating mechanism that renders that configuration from a much more use-friendly configuration file, with well defined configuration points, which leads to uniform and standardized deployments that can be better understood and analyzed.
This approach then also allows for a GitOps approach where the expected state of the system can be fully tracked in version control.
diff --git a/docs/mkdocs.yml b/docs/mkdocs.yml
index f42c0fc..ae0bfb9 100644
--- a/docs/mkdocs.yml
+++ b/docs/mkdocs.yml
@@ -1,77 +1,78 @@
---
site_name: Kolab Documentation 4.0.16
site_url: https://docs.kolab.org/
repo_name: kolab-infrastructure
repo_url: https://git.kolab.org/source/kolab-infrastructure
theme:
name: material
palette:
primary: grey
accent: custom
font:
text: Nunito
logo: assets/mail-blue.png
favicon: assets/mail-blue.png
features:
- navigation.sections
- navigation.instant
- navigation.tabs
- navigation.top
- navigation.tracking
- navigation.indexes
- search.highlight
- search.share
- search.suggest
- toc.follow
- content.code.copy
- content.code.annotate
# FIXME doesn't work with mermaid atm.
# It attempts to obtain mermaid over the url inside the container "http://0.0.0.0:8000" instead of what we use in the browser (http://localhost:9000).
# This is not just about the port, but the entire URL
# plugins:
# - privacy
extra_css:
- stylesheets/extra.css
markdown_extensions:
- admonition
- pymdownx.details
- pymdownx.superfences:
custom_fences:
- name: mermaid
class: mermaid
format: !!python/name:pymdownx.superfences.fence_code_format
nav:
- Home:
- index.md
- home/what-is-kolab.md
- home/kolab3.md
- home/contribute.md
- Overview:
- overview/index.md
- overview/distribution.md
- overview/kolabctl.md
- overview/logging.md
+ - overview/containerization.md
- Components:
- overview/mta.md
- overview/roundcube.md
- overview/kolab.md
- Deploy:
- deploy/index.md
- deploy/quickstart.md
- deploy/supported-platforms.md
- deploy/about-kolab-on-kubernetes.md
- Reference Architectures:
- deploy/reference-architectures/index.md
- Single Node K3s: deploy/reference-architectures/single-node-k3s.md
- Replicated K3s: deploy/reference-architectures/replicated-k3s.md
- Kubernetes Cluster: deploy/reference-architectures/kubernetes-cluster.md
- Networking: deploy/networking.md
- Administration:
- administration/index.md
- Notes: administration/notes.md
- Migration: administration/migration.md
- User management: administration/usermanagement.md
- Changing TLS Certificates: administration/changing-tls-certificates.md
- Cyrus IMAP: administration/cyrus-imap.md
- Postfix: administration/postfix.md
- Spamassassin: administration/spamassassin.md

File Metadata

Mime Type
text/x-diff
Expires
Sat, Apr 4, 8:48 AM (2 w, 5 d ago)
Storage Engine
local-disk
Storage Format
Raw Data
Storage Handle
ee/4b/6f99fdbe57b197abc27c806c33c4
Default Alt Text
(6 KB)

Event Timeline