consejo sobre instalacion en produccion

[Jos MeBo]

Buenas

LLevamos un tiempo estudiando la parte de sistemas de Odoo, sus diferentes formas de instalación, y las diferentes formas de instalar también los addons de OCA y de terceros, etc...

Ha llegado el momento de elegir una de las formas de instalación, pero no tenemos claras algunas ideas

¿Qué forma de instalación nos recomendais para un entorno de producción, teniendo en cuenta sobretodo los siguientes parámetros?

* facilidad de mantenimiento posterior, es decir, facilidad de aplicar actualizaciones para todo, tanto el propio odoo como sus dependencias como los addons de terceros

* qué sistema de los que existen lleva los parches más al día (paquetes de ubuntu generados por el propio odoo, paquetes pypi, directamente trabajar con repositorios git)

También por otro lado tenemos las dependencias de Python, ¿qué opción es mejor para llevarlas al día?  ¿instalarlas como paquetes de distribución de Ubuntu o instalarlas con pypi?

De momento la que más enteros lleva ganados para nosotros es instalar paquetes del propio sistema ubuntu para odoo y dependencias + paquete pypi para los addons de terceros como por ejemplo el de l10n-spain

Gracias, un saludo

[Pedro M. Baeza (Tecnativa)]

Prueba Doodba como solución todo en uno para todo eso que comentas:

https://github.com/Tecnativa/doodba

Un saludo.

[Jose R. Prieto]

Ahora mismo, y más que nunca, Doodba

Las mejoras que ha hecho Tecnativa son realmente buenas.

Hay que leerse la documentación, y entender como funciona, pero después, te facilita muchísimo el trabajo.

Eso sí, para producción, está pensado para usar Traefik; aunque es (relativamente) fácil adaptarlo para nginx.

No obstante, comentas que para vosotros os va mejor instalar Odoo por paquetes de Ubuntu (entiendo que hablamos de deb packages), y las dependencias de Python con pip.

Personalmente, ahí difiero bastante.

Que Pedro me corrija si estoy equivocado; pero si quieres tener la última versión actualizada de Odoo, la mejor opción es Github (rama estable, se entiende)

Con Doodba (y con otros) vas a poder escoger si quieres como fuente Odoo, u OCB (la versión de OCA); con Doodba, adicionalmente, con OpenUpgrade a mayores.

El ciclo de releases de paquetes Deb, aún en Ubuntu, o estoy muy equivocado, o va a ser más lento.

Después, dependencias; ten en cuenta que las dependencias dependen mucho de lo que instales.

Obviamente, tienes dependencias a nivel del propio OS; librerías, etc. Esas, sí, mejor paquetes deb / rpm / lo que use el OS

Las de Python, pip soluciona el problema con solvencia.

Pero también puede ser que necesites librerías Ruby (gems), para intérprete scss, por ejemplo..

Dependencias Java, si usas Jasper Reports...

LibreOffice/OpenOffice, si vas a usar py3o o similares...

Y seguro que me dejo más.

En general, Doodba te soluciona todo eso con comodidad.

Otra cuestión diferente es que quieras tener un sistema CI/CD con tiempos mínimos de updown, entonces tienes que construir otro tipo de sistema, generando imágenes Docker con todo lo que necesitas, y que simplemente hagas un docker pull en producción, y restart del Container de Odoo.

También se puede hacer a partir de Doodba; pero el tiempo de actualización de la base de datos, ese es casi imposible de eliminar.

Pero, vamos, en condiciones normales, tampoco deberían tener que hacerse tantísimas actualizaciones..

--
Has recibido este mensaje porque estás suscrito al grupo "Usuarios Odoo / OpenERP en España" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a openerp-spain-u...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/openerp-spain-users/CACSANCDwY9FxMyG7qzP28Ea%3DF2MGxu5W%2Bus2QU%2BWFAPH5cLE0A%40mail.gmail.com.

[Pedro M. Baeza (Tecnativa)]

Sí, uno de los problemas del paquete deb es que resuelve solo una parte del ciclo de despliegue de actualizaciones: la del código fuente de Odoo, siempre que dicho paquete esté actualizado, claro, que alguna vez se ha roto el sistema de publicación, pero luego queda actualizar el código fuente del resto de módulos (OCA y terceros), que también es importante en cualquier instalación que tenga algo más de necesidades, y luego la actualización de los módulos para reflejar los cambios del código en la BD. De nuevo para módulos Odoo no debería ser problema debido a su política de estabilidad, que hace que no sea necesario en el 99% de los casos eso de "actualizar módulo", pero para OCA y demás, sí que lo es, porque se innova y mejoran los mismos dentro de la misma versión, porque si no imaginad tener que aguantar hasta la siguiente versión para incluirlos...

Por eso creamos Doodba para responder a todas esas necesidades. Requiere pre-conocimientos de las tecnologías base (docker, git, invoke, etc), pero una vez pasada esa barrera, es lo más ágil y contiene las mejores prácticas que conocíamos o hemos ido aprendiendo a lo largo de nuestra experiencia.

Un saludo.

[Jose R. Prieto]

Es un muy buen trabajo :)

¿Hora de pasarlo a OCA?...

--

Has recibido este mensaje porque estás suscrito al grupo "Usuarios Odoo / OpenERP en España" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a openerp-spain-u...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/openerp-spain-users/CACSANCBg2mA38OmE18oRctwvmdMT10aAh6QqCaMLJCzHpxAB-Q%40mail.gmail.com.

[Jos MeBo]

Muchas gracias por la sujerencia de Doodba, como comentaba estamos empezando y no conocíamos ese proyecto

Hemos estado revisando un poco Doodba, es muy interesante, pero nos da la sensación de ser demasiado avanzado, también supone aprender nuevas tecnologías que de las que no tenemos ningún conocimiento como docker, etc... Vemos este proyecto más orientado a implantadores que para una simple instalación local interna. Tampoco hemos visto mucha documentación o tutoriales por Internet, quitando del fichero README del propio GitHub

Realmente solo necesitamos las funciones del Odoo base, y como mucho algún modulo de l10n-spain.

Hemos visto que cada pocos días actualizan los paquetes Ubuntu del repositorio base de Odoo. Como es una instalación interna, como mucho se realizarán actualizaciones semanales o quincenales, las típicas para aplicar parches de seguridad.

Un saludo

[Pedro M. Baeza (Tecnativa)]

Como quieras, pero esas palabras "simple instalación local interna" pueden ser tu tumba, ya que es igual de compleja que cualquier otra implantación y tiene los mismos retos. Rebajar los estándares a aplicar (seguridad, forma de despliegue, etc), lo único que os hace es tener luego problemas a posteriori, pero vosotros decidís.

Un saludo.

[Jos MeBo]

Hola Pedro

Nos estamos asustando, puedes ampliar un poco la información sobre ser nuestra tumba

¿Qué problemas puede dar tener Odoo base instalado como paquete ubuntu de su repositorio oficial y aplicar parches con apt upgrade?

¿Y con respecto a Doodba, hay más documentación a parte del readme de GitHub?

Muchas gracias por todo

El miércoles, 20 de mayo de 2020, 19:15:58 (UTC+2), Jos MeBo escribió:

[Pedro M. Baeza (Tecnativa)]

Es que un deployment de Odoo es mucho más que el paquete deb:

- Proxy inverso.

- Encriptación SSL.

- Configuración por defecto sana.

- Relay de correo.

- Protección DDoS.

- Entorno de prueba bastante sencillo de generar.

- Repositorios satélites actualizados.

- etc

Y gran parte de esa colección de buenas prácticas es lo que pone Doodba. Es un todo en 1.

Un saludo.

[Jose R. Prieto]

El stack es más amplio que "Odoo + base de datos"

Hay quien instala así, sí...

... Y después, los problemas.

O que si Odoo va lento, que si no escala...

Aunque se haga la instalación desde paquetes, hay que configurar:

- proxy inverso (nginx o el que más te guste)

- Postgresql

- wkhtmltopdf

- dependencias varias que van a tener los módulos y no Odoo base

- El correo electrónico; tanto saliente como entrante (y reglas del firewall, etc)

- HTTPS, renovación de certificados, ..

- Backups

- Repositorios de módulos (y su actualización)

Eso, como mínimo mínimo.

A partir de ahí, ya para mejorar.

--

Has recibido este mensaje porque estás suscrito al grupo "Usuarios Odoo / OpenERP en España" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a openerp-spain-u...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/openerp-spain-users/CACSANCCBa7J_H189nuR5o9QzGFs9JDjm%2BWrXvscg5Mq5ykCqDg%40mail.gmail.com.

[Juanjo A.]

Hola, personalmente, probé doodba y me resulto complejo, pero sin duda completo y es un trabajo excelente.

Ahora me decanto por tener con docker la implementación, y un Makefile con todos los comandos que se requieren para el uso diario (backups manuales, sandbox, filestores, etc etc)

Con docker puedes tener un compose-file para postgres, odoo, traefik (SSL), haproxy, otra instancia con un cron para los backups periódicos, etc.

También tenéis soluciones instalar y listo, pero si se quiere tener controlada la instancia, tienes que conocer lo que comentan también.

Me da a mi, que mejor buscáis soporte para la instalación, porque te puedes encontrar con problemas de seguridad.

IMHO

Un saludo

JuanjoA

[Pedro Manuel Baeza Romero]

Juanjo, si Doodba es Docker!

Lo que hacemos es añadir una capa de conveniencia encima para que con ciertas convenciones de archivos, tengamos configurado de manera fácil todo. Por ejemplo, en odoo/custom/dependencies/pip.txt, tenemos un archivo para añadir las librerías Python que necesitamos para nuestro proyecto. En odoo/custom/src/addons.yaml, indicamos de manera sencilla los módulos OCA (o de cualquier otro repositorio), para que Doodba los popule.

También hemos avanzado mucho con el plantillaje, teniendo un asistente que te pregunta lo que quieres para tu proyecto. Tal vez deberías volver a echarle un vistazo.

Un saludo.

[Borja García]

Buenas,

Justo ahora estoy leyendo sobre Doodba y me parece muy interesante para usar docker junto con odoo.

Acabo de empezar y sólo he visto algún tutorial y leído la documentación que me he encontrado, pero no me queda clara una cosa.

¿Cómo se controla qué commit de odoo, y repositorios de la OCA se baja?

Es decir, por lo que veo (igual me equivoco, y puede que se me haya pasado) se baja el último commit de cada repositorio, pero con la rama común según la $ODOO_VERSION.

¿Pero si por lo que sea quiero actualizar un repositorio a la última versión y otro dejarlo en una anterior? (puede que si se trabaja con más de un odoo para clientes diferentes, en uno tenga que tener actualizado un repositorio de la OCA a lo último y en otro esa última versión me rompa algo propio, y mientras lo arreglo ese no quiero actualizarlo, pero sí otros)

¿Hay alguna manera de distinguir en el contenedor sobre qué versión de los repositorios se está bajando?

¿Se sabre sobre qué commit (o tag o cualquier otra manera de identificar qué código exacto tiene) se ha usado de cada repositorio?

Porque en el conf de los repos veo la versión, pero no he visto nada más.

¿Hay alguna manera recomendada de trabajar para ir actualizando las versiones de repositorios controladamente, y que no sea simplemente bajar la última?

Un saludo

[Pedro Manuel Baeza Romero]

El modo por defecto es trabajar siempre con el último código fuente que haya disponible cada vez que se reconstruye. Eso, unido a la herramienta click-odoo-update que actualiza lo que haya cambiado, es lo más óptimo para mantener una instalación Odoo con los últimos parches de seguridad y bugfixes. Piensa en un símil a las instalaciones Linux rolling-release. Alguna vez hay alguna pequeña regresión, pero se gana más que se pierde teniendo lo último siempre.

De todas formas, si quieres fijar un commit, es poner para cada repositorio el SHA de dicho commit en el archivo repos.yaml.

Un saludo.

[Borja García]

Ok,

gracias.

Sí, entiendo la filosofía del último código, que será beneficioso casi siempre, especialmente en clientes con instalaciones en desarrollo y vivas, pero era por si había algo pensado para los casos en los que se rompe algo por cambios ajenos en clientes con necesidades más modestas, y que, si piden un pequeño cambio y lo que se rompe es muy complejo a veces no sale a cuenta mantener.

Si con poner el SHA del commit se soluciona, lo tendré en cuenta, aunque espero que no sea necesario.

¡Muchas gracias!