Doodba Kubernetes

[JuanDCG]

Hello Doodba,

From my point of view, Doodba is the best approach with Docker and Odoo.

Just now, I'm trying to move Odoo to Multi Cloud Native based Infrastructures, with Terraform as Multi Cloud, and Kubernetes also for Multi Cloud Native, but for Deployments also, moreover, all the other stuff will be made within Kubernetes extensions and applications.

So, here, in Doodba project, I want to suggest a possible feature that could be investigated.

Could be possible translate Doodba templates into Kubernetes templates with Kompose?

Only suggesting the idea.

Thanks

[theangryangel]

At work we run a few Doodba based projects on k8s (Traefik 2 ingress, nfs storage, redis session management is critical for the larger installs), on our own hardware. Works fine with no issues...

We deploy using GitHub actions.

So far I’ve avoided kompose and we are using unique manifests per project and environment which are hand crafted and basically don’t change once created.

Each of our projects has different needs (job queue, separate worker for cron, etc.) that I’m yet to see a good way to make a helm template.

However I’m willing to see if I can take any of our minimal work and contribute it back.

[JuanDCG]

@theangryangel

Thanks for your manifests and for tell about your solutions.

In my case, I view things from other perspective because I'm of "middle-age-school",
and for this year I've the opportunity to innovate by researching and learning
cutting-edge technologies or also maybe well established open source projects.

I understand your infrastructure and there are some gaps. However, probably you don't need it just now. Because your HW side business is strong.

But I comment it if you like:

• I'don't know about the under layer bus, but if you provision homogeneous VM with ansible I find a new gap for me, I'm using Terraform.
  If your under layer be able to have a Terraform module to provision and ansible for custom configurations. here another disscussion

• If you are sysadmin by trade, Terraform should like you, because is like SysOps.

• With the Terraform declarative language you con specify all details for your k8s, networking...

• Theoretically Redis is the best option for session management at scale, like we are speaking in this discussion, all depend of your needs, always. About bottle neck in NFS I've a look of this Rook support NFS. I don't know if its match with your needs or if it is helpful.

• From my point of view, Odoo powerful is more in server side than in front end ( Odoo is changing its frontend ), so also is in database model. With a HA DB or horizontal scaling you have a powerful DB solution to scale up. Depend of your needs.

• For your ask, if you've a small environments use Doodba (Docker), if you want clustered Doodba solutions for ease admin use k8s ( and swarm doesn't work properly ), but like say Yajo, Doodba was born before k8s. So, is difficult adapt all the stuff of Doodba in k8s world ( If you want all in k8s ).

jejejej, It's not perfect, it's your reality, of course.

So, I've contrasted with my reality that it's not perfect also, but I can design theoretically to scale, and then put hands-on and a lot of hard work to achieve some reality open source for this year.

Just now, also, I haven't clarify about CI/CD with runbot.

On my project I would like use Argo

[yajo]

OK, since you're getting points into your thesis, remember an important one: on-premise deployments.

Terraform is great if you are happy with Google or Amazon owning your data, but otherwise it's just ornamental when compared with Ansible.

In any case, the ideal would be to decouple k8s provisioning with odoo ops management, on top of k8s. I think the 1st point will differ always from company to company, as stability vs. availability vs. price is something that affects you and your customers in different un-standarizable ways. The 2nd stuff (odoo ops over k8s+doodba) should be quite common to everybody. If you start your FLOSS project focusing on the 2nd problem, you'll have more success.

[JuanDCG]

Ok, @yajo, thank you for your feedback.

I try to be clear:

• I want to launch a FLOSS project with repositories of code, code samples as examples, and reference documentation with all the scenarios covered. But without Collaborators/Contributors I only can test it on public cloud.

• I want to achieve solutions that cover public, private and hybrid cloud through federated k8s.

• But I've only access to public cloud with a free account.
  This is the reason for use Terraform and Terragrunt workflow to provision infrastructures. Puppet, Chef, Ansible are also great. So I'll testing every k8s over GKE provisioned with TF, and yes, it is coupled. Besides, happy helming is inside TF. The entire Infrastructure is provisioned with TF. (In my case)

I'm going to assume that you have a private cloud/on-premise, and you don't need any services around Odoo CE because you have boundaries, DNS, SMTP, SSH, Logging and Monitoring...and you have any provision layer.

So, you only need a custom implementation of Odoo CE for your k8s provisioned.

Here, begin to play the team Doodba:

• The only Helmv3 ( Artifact Hub ) package for Odoo CE is from Bitnami and uses docker images from bitnami.

• I don't know how to play with Doodba. I don't know about all stuff inside Doodba yet.

• The original comment of this thread talk about if create from scratch a docker image customized to live inside a new helm chart.

• I would like to play with you, and right now, I tested if changing image repository to tecnativa/doodba and with tag:latest inside the values of Bitnami chart, could be possible and ... magically ; ), Bitnami overwrite these custom values... Let me how is the best approach to build this image.

• But, for now, it is my unique possible path to contribute to Doodba.

• If we could build a custom image:tag with your opinionated Doodba, I could test it from GKE, and then we could learn from bitnami chart and build another Helm package.

• My main personal goal is to learn, so, I'm learning about TF, K8s, Helm and Odoo CE...

I hope that my comments are useful for community, and I would like focus on the right approach, but since its depends on the implementation there are many approaches.

[yajo]

I would like focus on the right approach

I'd say it is:

1. Use doodba for devel and CI.
2. After CI is done, push the built image to registry.
3. From there on, use helm to deploy that new image to staging/production.

[JuanDCG]

Ok, thank you for clarify. I'll try to play with it.

[JuanDCG]

I would like invite you if you are interested on discuss about approach solutions at my organization team.
@theangryangel @yajo

[JuanDCG]

Hi, only to play and for fun:

If there are anyone on test the Bitnami/Odoo Helm v3 from Artifact Hub on GKE, I've created a forked-based repository to customize Odoo/bitnami, and evaluate if build another Helm package from scratch for Odoo CE is a good and reasonable option.

Maybe, could be possible build from scratch it with know-how about Odoo CE of Doodba Team, @theangryangel @yajo

[theangryangel]

If it's of any interest to anyone, I have started a WIP helm chart for Doodba based deployments. It's definitely opinionated to the way we work, and it's absolutely not final (we're currently in "live for demo and test installs, but cautiously testing phase")

https://github.com/GlodoUK/helm-charts/tree/master/odoo

Support out of the box for;

• Separate web and OCA job queue instances
• Custom config snippets and all the usual env vars (when we need it we'll add custom env vars)
• click-odoo-upgrade on upgrade via helm hooks (I'm yet to test this on a busy install, but I predict there will be some change here - normally we have to scale down a busy install. Small installs it's fine as-is)
• Ingress via Traefik IngressRoute (no support for custom middlewares yet, but it's in the pipeline)
• External-dns support via the DNSEndpoint CRD

On the todo list;

• cert-manager support (grumble Do not attempt to renew certificate no longer used traefik/traefik#3376)
• redis instance support (maybe)
• better docs
• tests when I determine what we should be testing the chart for and where our pain points lie

Deployment and management of PostgreSQL is not a concern of this helm chart and likely will never be.