@Régis Behmo we built a one-click deployment POC last year on Kubernetes (OpenShift) using Ansible. I see that you coded a nice k8s.py script – considering that Ansible is written in Python, it’s all essentially the same, of course. Some advantage of using Ansible is that it enables you covering all technologies in scope (e.g., MySQL, MongoDB) from a single tool, and it has a deployment/workflow management system Tower (the open source version of it). Somewhat unfortunate, a couple of years ago, Ansible zigzagged into a patch of complete disarray, versions and styles incompatibility, which resulted in many people criticizing the tool, and rightfully so. However, I think that their late-2018 software is well-designed and stable. Working with OpenShift, we saw how the product team re-wrote the Ansible books completely, dropped the old-style ones and produced a simple, clean and fast installation suite for quite a complex product base. Just wish EDX can do that one day… So, I would give Ansible a chance. Although, as we know, the era of installers and installable software fades away.
In the POC, we had a complete system rolling out from scratch in under 5 min. Of course, we used a pre-migrated MySQL database. With all due respect to the migration concept of Django, the incremental one is not sustainable when doing multiple rollouts, and completely not necessary. One area of concern was the location of the auxiliary services such as Memcached and RabbitMQ inside the k8s cluster – to avoid the latency of traffic when placing components across disparate hardware units and data centers. It probably makes sense co-locating Memcached in the same pods with the Django servers. RabbitMQ is a relic from the past. If we keep the LMS and CMS close to each other and put RabbitMQ near-by as well – we end up with huge pods or tight placement rules that defeat the purpose of doing k8s. So, probably, just bite the bullet and place RabbitMQ anywhere and absorb the latency and cross-zone traffic cost. Lastly, image build can also be hugely optimized to cut down on the deployment effort for minor code fixes, although that involves image updates, which some folks think are anti-docker. Bottom line, adopting VM-centered designs to modern techs is not easy, but possible. On Wednesday, March 20, 2019 at 7:24:37 PM UTC+8, Régis Behmo wrote: > > @Do Won Kim I'm curious, what tool(s) do you use for deploying on multiple > servers? Ansible, Chef, Puppet, Terraform, Docker swarm, Kubernetes? > Carefully crafted bash scripts? Something else? > > As the principal maintainer of Tutor (https://github.com/regisb/tutor), > I'm currently considering my options for deployment of Tutor/Open edX on > multiple servers. There are many different ways to do this and I'm trying > to figure out the best approach for the community. Btw, I'm also interested > in answers from other people in the community :) > > > -- You received this message because you are subscribed to the Google Groups "General Open edX discussion" group. To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/f61d6b6e-0c27-446d-850c-c10cfa037b34%40googlegroups.com.
