* 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>
https://github.com/Human-Connection/Human-Connection/pull/1543#pullrequestreview-287593264
Thinking about it, I really ask myself why I did not find this solution
earlier 🙈
Of course, you don't want to share the generated `buildDir`
with the host system. If you happen to share the `webapp/` folder,
simply point NuxtJS to a build directory somewhere else. Easy!
* Use `production` docker images for cypress tests. As one of our contributors
pointed out: It is bad practice to end-to-end test sth. else than the actual
production images.
* Have a dedicated `docker-compose.travis-integration.yml` to test
backend integration tests. The backend *needs* a database when doing
integration tests. So there is no way around using docker-compose. But
we could stop using the `build-and-test` stage when we do cypress tests.
* Remove a couple of unused ports and DRY `docker-compose.override.yml`
* Build and tag all images first and then run `docker-compose .. up` - I
hope this will not rebuild the image.
* Reduce docker image size
Here are the issues
* webapp was built with `NODE_ENV=production` but started with
`NODE_ENV=development`
* using the provided `docker-compose.travis.yml` the command `yarn run
start` would look in the wrong folder
* removed duplicate environment definition
.. but enable it by default for `docker-compose.override.yml`. If the developer
uses `docker-compose` we can safely assume that a local smtp server for
development is running.
