Date
- Time and lack of expertise is keeping people to run Magnolia in Docker and / or Kubernetes.
- No documentation on dockerizing Magnolia
- Request for a how-to / Magnolia-Dockerfiles
- Restoring MySQL-Data whilst starting Magnolia-Docker-Images locally
- Storing everything in the database (including assets) might be easier for spinning up new database instances (in terms of scaling)
- S3-Adapter / connector for assets
- Autoscaling for Magnolia Public instances
- Complex because of license issues
- Most devs starting new public instances by hand
- There is a need for unlimited license if you do autoscaling
- Configuration (for example add subscribes) for new started Magnolia instances could be done via Magnolia REST-API
- Google Cloud Disks (https://cloud.google.com/persistent-disk/) for Snapshots to create feature based Kubernetes clusters
- Spinnaker (https://www.spinnaker.io/reference/providers/kubernetes/) for transferring data to new clusters
- Every new version built by developers generates a new Docker image
- Base image for Magnolia based sites
- Azure SQL / Google Cloud SQL
- Rate Limiting leads to queueing
- Vertical scaling for databases
- Demand for showing / deleting version history
- Managing data and scaling in modern cloud environments is still complicated
Popular Technologies:
- Docker is used by many
- Packer (https://www.packer.io/)
- Kubernetes (more for orchestration than for scalability)
- Docker Compose for local development
- Some went back to starting Magnolia locally because of the poor Docker performance on Apple hardware
- Docker Swarm
- Ansible / SaltStack
- GitLab CI
- Terraform
- ZooKeeper
Session-Management for multiple Public-Instances:
- Sticky Sessions managed in the Loadbalancer
- Redis to store session data (only works in the same region)
- Try to avoid having state in the Backend (requires decoupling frontend from the backend)
Neoskop-Docker-Images: