Ekylibre dans docker

[wil]

Bonjour,

N’étant pas un grand familier de ruby, je dois avouer que j’ai eu pas mal de problème juste pour l’installation d’Ekylibre.
D’ailleurs, si je suis à la lettre le mauel sur github, j’ai systématiquement une erreur lors de la première commande rake sur la db.
Après quelques heures et une installation qui semble réussie, je me demandais si vous aviez envisagé un container Docker, près à l’emploi, ne serait-ce que pour des phases de test ou de développement ?
Est-ce que vous pensez que ça pourrait être une bonne idée ?

En tout cas, Merci pour tout.
Wil.

[Coren]

Bonjour,

Oui, on pense que c’est une bonne idée ! On en a encore d’autres priorités, mais on va s’y attaquer sérieusement une fois qu’elles seront levées.

Concernant l’installation, j’ai légèrement modifié la commande rake.

Est-ce que ça te semble plus correct ?

Coren

[wil]

Est-ce que ça te semble plus correct ?

C’est effectivement ce que j’avais fait…

J’en profite ; la commande gem install bundler refuse de s’exécuter à moins de modifier la version de FFI dans Gemfile.lock, ligne 148:
ffi (1.9.5)

Vais finir par comprendre un peu mieux ruby…
Merci pour tout…

[Coren]

Avec le paquet, on utilise ruby2.0.

Ruby.20 est dans un état un peu spécial sur Ubuntu 14.04. Il est disponible, mais ce n’est pas le ruby par défaut. Ça complique et complexifie certaines tâches.

Normalement, grâce au .bundle/config fourni par le paquet, il n’est pas nécessaire de l’exécuter.

Néanmoins, si besoin de lancer bundler, il est inclus dans le paquet ekylibre-gems.
À ce stade, il est possible de l’invoquer de cette manière:

 ruby2.0 /var/lib/gems/2.0.0/gems/bundler-1.7.3/bin/bundle ...

À terme, une mise à jour de la distribution devrait permettre un switch entre version, et donc une meilleure intégration.

[wil]

re,

Avais-tu déjà essayé de l’installer dans Docker @Coren ?
Parce que je bloque sérieusement (aussi) sur la config de nginx de l’hôte.

2014/10/08 14:08:16 [crit] 27352#0: *4 open() "/var/cache/nginx/proxy_temp/2/00/0000000002" failed (13: Permission denied) while reading upstream, client: ........... server: ekylibre..........., request: "GET /assets/application-25fd8b137bd2b4d60ac8e0b5f49dbab4.js HTTP/1.1", upstream: "http://........./assets/application-25fd8b137bd2b4d60ac8e0b5f49dbab4.js", host: "ekylibre......., referrer: "http://ekylibre......../authentication/sign_in"

Je pensais désactiver le cache dans la configuration d’Ekylibre, mais échec total également.
Si je supprime le dossier /usr/share/ekyibre/public/asset/ qui contient les fichiers, je n’arrive plus ensuite à la régénérer…
Bref, si tu as réussi à le faire, par curiosité…
On est bien d’accord, rien d’urgent dans tout ça…

Merci.
Wil.

[Coren]

Voici ce qu’on utilise comme conf. nginx:
La conf upstream:

upstream www.ekylibre.org_unicorn {
  
  server     unix:/usr/share/ekylibre/public/../private/unicorn.socket  fail_timeout=0;
}

La conf vhost:

server {
  listen                *:80; 
  server_name           www.ekylibre.org;

  access_log            /var/log/ekylibre/nginx_access.log main;
  error_log             /var/log/ekylibre/nginx_error.log;

  return 301 https://www.ekylibre.org$request_uri;
}

server {
  listen       *:443 ssl;

  server_name  www.ekylibre.org;

  ssl on;

  ssl_certificate           /etc/nginx/www.ekylibre.org.crt;
  ssl_certificate_key       /etc/nginx/www.ekylibre.org.key;
  ssl_session_cache         shared:SSL:10m;
  ssl_session_timeout       5m;
  ssl_protocols             SSLv3 TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers               HIGH:!aNULL:!MD5;
  ssl_prefer_server_ciphers on;
  client_max_body_size 10m;

  access_log            /var/log/ekylibre/nginx_access.log main;
  error_log             /var/log/ekylibre/nginx_error.log;

  etag off;

  root                  /usr/share/ekylibre/public;
  add_header              X-UA-Compatible "IE=edge";
  add_header              ETag "";
  location /private {

    root  /var/ekylibre;
    internal;
  }
  location / {

    error_page 403 /403.html;
    error_page 404 /404.html;
    error_page 422 /422.html;
    error_page 500 /500.html;
    try_files @uri @app;
  }
  location ~ "^/([0-5]{3}.html|system|images|assets|favicon.ico|robots.txt)" {

    add_header Cache-Control public;
    expires 1y;
    gzip_static on;
    break;
  }
  location @app {

    proxy_pass          http://www.ekylibre.org_unicorn;
    proxy_read_timeout  90;
    proxy_connect_timeout  90;
    proxy_redirect  off;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        X-Sendfile-Type X-Accel-Redirect;
    proxy_set_header        X-Accel-Mapping /usr/share/ekylibre/private/=/private/;
  }
  error_page 502 /502.html;
}

La conf nginx en tant que telle:

gzip            on;
gzip_min_length 1000;
gzip_comp_level 5;
gzip_types      application/json text/css application/x-javascript application/javascript;
proxy_cache_path /var/nginx/cache keys_zone=one:10m max_size=200m;

Mais je ne suis pas sûr que ça soit lié. Ton message d’erreur indique un problème de droit sur la lecture du cache nginx.

Pour regénérer les assets, ça se fait avec un bundle exec rake2.0 assets:precompile

Tu me fais penser qu’il faut que je mette à jour la conf example du paquet, il y avait qq défauts dessus que j’ai corrigé depuis.

Note que si tu y arrives, le Dockerfile nous intéressera :).

[wil]

Pour regénérer les assets

Cool, merci…

Pour Nginx, ma première erreur était de vouloir tout mettre dans le container (Nginx, Postgresql, Ekylibre, etc…).
Ce qui fait que j’aurai eu 2 nginx qui tourneraient… 1 sur l’hôte et un second dans le container. En prenant en compte les headers + le cache, ça n’est pas vraiment tenable… Et c’est loin de ce qui est recommandé par Docker d’ailleurs.

Du coup, je n’ installerai pas nginx dans le container.

Mais pour démarrer correctement Ekylibre, je voulais te demander la commande exacte que je devrais utiliser pour lancer unicorn depuis le fichier un fichier de conf production.rb s.t.p.
Ekylibre est installé avec apt depuis le dépôt sur une unbuntu 14.04
Environnement production donc (si j’y arrive avec l’environnement de prod, ça devrait être plus simple pour un env de dev je penses…)

Je ne voudrai pas utiliser /etc/init.d/ekylibre, mais plutôt supervisord. Comme je te disais, je découvre complètement le fonctionnement de ruby, ruby on rails -_-’

En parallèle, est-ce que tu penses que la gestion du cache par ruby plutôt que nginx pourrait impacter les perfs ?
ça risque d’être un casse-tête sinon (partant du principe qu’on lancerait plusieurs containers d’Ekylibre sur le même hôte).

Note que si tu y arrives, le Dockerfile nous intéressera

Bien sûr
Suis arrivé à quelque chose de pas trop crade. Il reste la question de la configuration maintenant.

[Coren]

Mais pour démarrer correctement Ekylibre, je voulais te demander la commande exacte que je devrais utiliser pour lancer unicorn depuis un fichier de conf production.rb s.t.p.

Regarde le fichier /etc/default/ekylibre, ça devrait répondre à ta question :).

Je ne voudrai pas utiliser /etc/init.d/ekylibre, mais plutôt supervisord. Comme je te disais, je découvre complètement le fonctionnement de ruby, ruby on rails -_-’

Je ne connais pas supervisord. D’ici quelques mois, on va intégrer quelque chose qui semble y ressembler: bluepill. Ça nous permettra de lancer reddis et/ou sidekiq de manière simultanée à l’applicatif. Note que nous comptons intégrer bluepill de telle manière à ce que d’un point de vue OS, ce soit toujours service ekylibre start

En parallèle, est-ce que tu penses que la gestion du cache par ruby plutôt que nginx pourrait impacter les perfs ?ça risque d’être un casse-tête sinon (partant du principe qu’on lancerait plusieurs containers d’Ekylibre sur le même hôte).

Ekylibre ERP a déjà un cache pour tout un tas de choses sur les éléments dynamques.

Je ne suis pas sûr de savoir comment le configurer pour qu’il serve les fichiers statiques. Ce sera forcément plus lent et beaucoup moins bien fait qu’un code en C éprouvé comme Nginx.

En plus de problème de performance, l’application est pré-configurée pour avoir un nginx en frontal qui sert les assets & les fichiers via des en-têtes ad’hoc (c’est la section sur X-Accel-Mapping de nginx qui s’en occupe).