Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

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



  • 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:

Magnolia SRE's base docker image:



  • No labels