Re: [Health-dev] DevOps

[Marc Murray]

Hi Carlos and Everyone, 

In my work, I have to manage (now) 6 production instances of GNU Health and 4 demo/test instances. All this is happening while we're still doing development on new modules and doing maintenance and bug-fixes on the stuff that's in production. The best part is, we have an EXTREMELY small team handling the technical details (installation, backup, upgrade etc).

While all this is happening, we have other stakeholders making plans to roll out new instances in other locations and those new instances need to be managed and updated like all the others.

This is how we do it:

• we use virtualenv
• for each major version of gnuhealth or our own modules, we use a different virtualenv
• they are all located in /opt/health/envX.Y  where X.Y is our version number. Internally we have a mapping of our version to GNU Health version. e.g. our version 1.2 depends on modules from GNU Health 2.8. Our 1.0 was GNU Health 2.6 etc
• create a gnuhealth user with home directory /var/local/gnuhealth
• the virtualenv in /opt/... is owned by root or by another user (e.g. healthadm) - as an additional security measure
• everything is installed and updated using pip - even our internal private packages that are not on PyPI
• We have an internal python package server[1] that automatically mirrors stuff from pypi.python.org.
• For packages that we upload, it does not try to mirror those
• GNU Health, we download as source and upload it to our internal package server. This way, we control the version that is installed to our servers
• For each type of instance, we have a module that depends on the required modules. e.g. moh_health_centre_profile, moh_hospital_profile.
• Even without updating the moh_xyz_profile module, we can still call pip install -U trytond_moh_xyz_profile and it will install updates for all dependencies where they exist.

Backups are done using rsync and barman[2].

So, while I've never used Vagrant, I can understand your desire to have "infrastructure as code". What I have laid out above, if you follow our use of pip, you should be able to reliably control updates to specific modules from within your vagrant scripts.

The reasoning behind using different virtualenv for different version, is to allow for an easy rollback if the upgrade fails at the database upgrade stage. If that happens, we restore the database that was backed-up before upgrade and just start trytond from the old virtualenv while we go off to figure out the issue on a non-production machine. This way, we have had very little down-time.

I hope this helps. 

[1] Our internal PyPI server is an installation of localshop - https://pypi.python.org/pypi/localshop 
[2] Barman is an awesome tool for postgresql backups - http://www.pgbarman.org/ 

---
MM

On Tue, 2016-04-05 at 15:17 -0500, Carlos Eduardo Sotelo Pinto wrote:
>     Hi
>     
>     
>     I am looking something liek that, I was to having the whole deployment [ install / upgrade / upgrade ] on code using a bos like vagrant or docker in order on havin continue sintegration and continues delivery
>     
>     
>     I have an script for tryton working on that using vagrant, and any change done is no possible to keep it as part of the process without edit the deployment scripts
>     
>     
>     Best regards
>     
>     
>     2016-04-05 14:27 GMT-05:00 Axel Braun <address@hidden>:
> >         Hi,
> >         
> >         Am Dienstag, 5. April 2016, 13:59:56 schrieb Carlos Eduardo Sotelo Pinto:
> >         >
> >         > Yes, you are right, however it is far from having "Infraestructure as
> >         > code", what I mean is having health on a way on working as Continues
> >         > Delivery and Continues Integration, considering that implementing ERP
> >         > requires more than just install
> >         
> >         Definitely, continuous adaption is part of this.
> >         
> >         I used to run a productive Tryton environment, and my target was always to
> >         have as least as possible administrative effort.
> >         So for the Tryon system we used packages from OBS (build.opensuse.org)
> >         
> >         The enhancements were implemented as separate package, build as well on OBS,
> >         but without disclosing it to public.
> >         
> >         Both are installed with system package management. Updates on base package
> >         automatically trigger a rebuild of depending packages, so the whole
> >         environment is always up to date, with minimal effort.
> >         
> >         Just as additional thought
> >         Axel
> >         
> >     
>     
>     
>     
>     -- 
>     Carlos Eduardo Sotelo Pinto
>         Senior Software Analyst Developer
>         Claro RPC +51983265994 | MOV RPM( # ) +51 966110066
>         GTalk: address@hidden | Skype: csotelop
>         GNULinux RU #379182 | GNULinux RM #277661
>     
>     
>     No availability between 08:30 and 18:00, I will answer as soon as posible
>     
>     
>     Please consider the environment before printing this email
>     Join the campaign at http://thinkBeforePrinting.org
>