Verified Commit 94c9f643 authored by Dmytro Bogatov's avatar Dmytro Bogatov 💕

Complete K8S migration.

parent c1d81b44
Pipeline #2510 failed with stages
in 11 seconds
<!-- cSpell:ignore SDKJF 5432 SMDFKL sdahjdjhd _678 ajsdvbja asgfdk _876 ajhsvdjh yourdomain logmessage -->
<!-- cSpell:ignore SDKJF 5432 SMDFKL sdahjdjhd Kubernetes _678 ajsdvbja asgfdk _876 ajhsvdjh yourdomain logmessage -->
# Configuration
......@@ -28,7 +28,7 @@ Configuration is built in the `Startup` method and is available for [Dependency
## User perspective
It is required to supply `appsettings.yml` file as a *docker secret* launching the application with `docker stack deploy`.
It is required to supply `appsettings.yml` file as a *docker secret* when deploying the application to Kubernetes.
Please, refer to [Deployment section](/deployment/) to download example config and supply it as docker secret.
<!-- When [deploying with script](deployment/) it is possible to supply *example configuration* to get app up and running. -->
<!-- Then user is free to change the configuration and restart the app. -->
......
<!-- cSpell:ignore Kubernetes -->
# Deployment
## Deploy to swarm (preferred way)
## Kubernetes
Officially supported deployment strategy is using Kubernetes.
Please, see [Kubernetes docs](https://kubernetes.io/).
I have to assume some basic experience with Kubernetes.
You can deploy most of the system right away with the following command
kubectl apply -f https://git.dbogatov.org/dbogatov/status-site/-/jobs/artifacts/master/raw/deployment/config.yaml?job=release-deployment
You also need to supply your settings
kubectl create secret -n status-site generic appsettings.production.yml --from-file=/path/to/config.yaml
where your settings reside in `/path/to/config.yaml`.
This will download the config file from CI and apply it against your cluster.
It is recommended to inspect the file before applying it for security considerations.
This config creates a namespace `status-site` and creates resources within it.
It creates tuples deployment-service for each part of the system.
Components are designed to communicate with each other by names provided in config.
Each component also gets `appsettings` secret mounted as volume.
Lastly, database needs a stable persistent storage, so config include Persistent Volume Claim for 10 GB.
It is cluster administrator's responsibility to provide Volumes that meet claims.
You may adjust the claim's capacity if needed.
By default, all services are not replicated (i.e. replication factor 1).
You may want to adjust this parameter.
Be careful, though.
The only components that are safe to replicate are `docs`, `ping` and `web`.
If `web` is replicated you may have issues with authorization, as one replica generated the cookie and another one does not recognize it.
I am working on this issue.
## LEGACY: Deploy to swarm (preferred way)
> This is the old way to deploy the system.
> It is not officially supported, but will likely work.
Status site is designed with swarm in mind.
The preferred way to deploy the system is using `docker stack deploy` command.
......
......@@ -308,7 +308,7 @@ build-deployment () {
mv services/namespace.yaml config.yaml
cat services/**/*.yaml >> config.yaml
cat sources/volume-claim.yaml >> config.yaml
}
## DEBIAN PACKAGE
......
......@@ -30,6 +30,8 @@ spec:
value: "statususer"
- name: POSTGRES_PASSWORD
value: "relyOn1InternalSwarmNetwork"
- name: PGDATA
value: "/var/lib/postgresql/data/db-files/"
volumes:
- name: database-persistent-storage
persistentVolumeClaim:
......
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
......@@ -8,6 +9,6 @@ spec:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: do-block-storage
storage: 10Gi
# storageClassName: do-block-storage
---
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment