mirror of
https://github.com/Ocelot-Social-Community/Ocelot-Social.git
synced 2025-12-12 15:25:57 +00:00
* feat(other): major improvement of deployment Motivation ---------- Kubernetes: * backend becomes a statefulset (exclusive volume mount) See: https://spacelift.io/blog/statefulset-vs-deployment * implement neo4j backup with job Docker: * consistent targets across all dockerfiles * remove redundant labels * remove unnecessary build args * remove obsolete networks * remove development dependencies for production Rebranding: * add image tags for local tagging and pulling * use Github's docker build workflows * use Github container registry * ONBUILD to simplify caller Dockerfiles * docker compose for branding Tooling: * same node --version as in dockerfile Docs: * missing step in README.md * refactor: remove submodules It's better to keep them all in a separate repository * improve kubernetes chart * better image tag defaults * split neo4j into its own chart (for re-use) * use application defaults where possible * optional resources for all pods * remove obsolete key/value pair from secrets * remove obsolete build argsand and add labels for neo4j enterprise * env vars for webapp * allow to define redirect domains Define a list of Domains that redirect to the domain of the project. The idea is to provide the ability to redirect eg. www.domain.tld to domain.tld * remove maintenance part regarding database * move backup job outside template folder * name the ingress * updated ingress * handle empty case of middlewares * try to default the ingress * use quote * restore todo-next-update * fix docu check * fix naming * try using prod:migrate * try using override config * copy src folder * try using base as image instead of build * fix test build * force build * comment for the problem * fix webapp tests (potentially) --------- Co-authored-by: Ulf Gebhardt <ulf.gebhardt@webcraft-media.de>
25 lines
1.1 KiB
YAML
25 lines
1.1 KiB
YAML
apiVersion: v2
|
|
name: ocelot-social
|
|
description: A Helm chart for ocelot-social
|
|
|
|
# A chart can be either an 'application' or a 'library' chart.
|
|
#
|
|
# Application charts are a collection of templates that can be packaged into versioned archives
|
|
# to be deployed.
|
|
#
|
|
# Library charts provide useful utilities or functions for the chart developer. They're included as
|
|
# a dependency of application charts to inject those utilities and functions into the rendering
|
|
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
|
|
type: application
|
|
|
|
# This is the chart version. This version number should be incremented each time you make changes
|
|
# to the chart and its templates, including the app version.
|
|
# Versions are expected to follow Semantic Versioning (https://semver.org/)
|
|
version: 0.1.0
|
|
|
|
# This is the version number of the application being deployed. This version number should be
|
|
# incremented each time you make changes to the application. Versions are not expected to
|
|
# follow Semantic Versioning. They should reflect the version the application is using.
|
|
# It is recommended to use it with quotes.
|
|
appVersion: "3.2.0"
|