The development and basic documentation of a Kubernetes cluster for TYPO3 running on Amazon Web Services (AWS) as a reference architecture. The implementation will use Terraform (Infrastructure as Code) to enable even non-experts to set up the technology stack easily.
The project also includes building a TYPO3 Docker image tailored for the Kubernetes cluster and (re-)usable for other projects. The cloud-based architecture will use services such as Amazon Elastic Kubernetes Service (EKS), Amazon RDS Aurora Serverless cluster for MySQL as a decentralized database engine, and AWS Secrets Manager to securely store secrets, among other components.
The setup aims to achieve high availability standards, automatically scale in and out depending on the current load, and follow AWS’s security best practices.
What do you want to achieve by the end of Q2 2024?
(1) Cloud-based infrastructure developed, tested, and made public as Terraform files in a Git repository.
(2) Basic documentation as Markdown files to guide users through the required steps to deploy the infrastructure using their own AWS account.
(3) Basic instructions on how to customize the TYPO3 Docker image (e.g. for own projects), ready to deploy on the Kubernetes cluster.
What is the potential impact of your idea for the overall goal?
Improvement of TYPO3’s reputation as an enterprise-level open-source content management system that can be deployed as a containerized application in the “cloud” using Docker and Kubernetes as top-modern DevOps technologies (pseudo-serverless).
Users can deploy their Kubernetes cluster, build their own Docker images, and run a TYPO3 site (for example, featuring the Introduction Package as a proof-of-concept) on AWS by following step-by-step documentation.
The infrastructure aims to reflect a reference implementation that users can customize and extend to meet their project requirements.
Which budget do you need for your idea?
7.500 Euro
This sounds like a great initiative! Reference implementations will make it easier for people to start using TYPO3 and showcase the power of the CMS when running it on cloud solutions.
We definitely need documentation and “cookbooks” around running and maintaining TYPO3 on a real life infrastructure.
Having AWS related recipes is fitting into that area.
In my opinion, we should first define more general best practices around infrastructure e.g. “how to run TYPO3 on multiserver environment” (what to configure and how, what resources to share and how, are some 3rd party extensions required, what are known issues or limitations…, what options there are to choose and what are the pros/cons between them) before we define a specific cookbooks for a single cloud provider (AWS).
And these best practices should be part of the TYPO3 official documentation.
Do you consider setting up these best practices part of the initiative?
I agree with you on this topic. Extending the TYPO3 documentation by adding information about modern infrastructure setups — including distributed setups — is a crucial mission.
Running containerized applications on Kubernetes (k8s) is considered a state-of-the-art DevOps approach today. The reference architecture I plan to build and document will allow users to deploy the solution themselves and customize it to meet their individual project requirements. It will also showcase TYPO3’s capability to run as a containerized application in Docker containers on k8s.
This aspect is a critical success factor for an enterprise CMS today, and we should publish resources that strengthen TYPO3’s reputation among its competitors in this regard.
Although the points you listed are related, the project focuses on Kubernetes clusters.
A documented reference architecture for a well-known cloud provider such as AWS encourages experts with experience in other cloud environments to follow. Having said that, both Kubernetes and Terraform are vendor-agnostic. The insight gained by this project can be reused in other environments and similar initiatives. It does not matter on which (cloud-)infrastructure Kubernetes runs at the end of the day.
If the project goes ahead, I would certainly approach the Documentation Team to discuss if and how the documentation produced in this project can be integrated into the TYPO3 documentation once finalized.
I see much bigger value in setting up best practices versus showing yet another way of doing X.
Without first defining and agreeing on basics (decisions you will have to take anyway when writing terraform) I fear that the result of your work will not gain adoption.
I agree that running apps on k8s (especially when everything is defined as infrastructure as a code) is a good way of operating. Whether its a state of the art for a CMS it depends on multiple factors (also non technical ones like who will maintain the infrastructure and keep it running, company policy…).
From my experience its rather uncommon see TYPO3 running on k8s. Much more common is to see TYPO3 running on some kind of multiserver environment.
Thats why I see much bigger value for community in setting up foundations which are useful for everybody, before doing more specific solutions.
I think we’re limiting ourselves if we see generalized best practice as a requirement for specific implementations. Best practice can be derived from well-documented implementation examples or be a basis for discussion of what the best practice should be. After all, perfection is the enemy of good.
I agree that we should have more documentation on deployment best-practices, but I also think that hard to make something useful for everybody without using some platform-specific examples. I have always gotten more out of a practical example than no example at all.
That there is anecdotal of TYPO3 being uncommon on k8s is not a reason to not demonstrate how to implement TYPO3 on k8s. If anything, a lack of a reference implementation could be the reason.
For that matter, I have real evidence that Composer usage is only roughly 50% or less. That doesn’t prevent the TYPO3 Documentation from being very Composer-specific (which I think is good).
I am in favor of this. It would lead to an “official” docker image for TYPO3 and a clarification of the different containerized use cases: local development, simple docker-compose, and k8s.
I fully support the suggestion. I share the desire that we should offer one or more official Docker images for TYPO3. However, I would like to refer to the focus of this budget idea as outlined above. The project includes building a TYPO3 Docker image tailored for the reference setup of the Kubernetes cluster at AWS that is (re-)usable for other projects. Creating and maintaining an official and versatile TYPO3 Docker image to be published at hub.docker.com is out of scope of this project though.
Having said that, I’d be more than happy to collaborate with stakeholders who intend to build a Docker image that can be deployed on the Kubernetes cluster on AWS and can also be published as an official Docker image at hub.docker.com and maybe on other platforms. I am sure that there are synergies.
As @oli4 correctly stated, this project would support the creation and aim to lead to an official Docker image for TYPO3 if it goes ahead.
