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

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: