Blog de dada

DevOps, bidouilleur et routard plein de logiciels libres

Apache

Nextcloud, PHP-FPM, Nginx et Kubernetes

Rédigé par dada / 14 janvier 2019 / 6 commentaires




Ma première installation de Nextcloud dans Kubernetes était basée sur l'image Docker contenant Apache2. Aucun souci notable au niveau de la synchro des agendas, des fichiers ou encore des contacts. Par contre, la génération des miniatures des photos s'est révélée être un drame : Apache s'emballait et entraînait le nœud sur lequel il tournait avec lui, dans la tombe. Il me fallait une solution, j'ai donc décidé de changer de conteneur et de prendre celui basé sur PHP-FPM.

Un pod avec deux conteneurs

On entend souvent la rumeur racontant qu'un pod ne contient qu'un conteneur. C'est souvent vrai, mais c'est aussi faux. Dans l'exemple qui va suivre, le pod gérant Nextcloud contiendra le conteneur officiel de Nextcloud et un conteneur Nginx.

Contexte

Pour suivre, sachez que mon cluster, celui grâce auquel vous lisez ces quelques lignes, gère son système de fichier avec Rook, dont j'ai déjà parlé ici. Mes nœuds sont chez Hetzner, ce sont des CX21, du cloud public donc, et mes services sont exposés en NodePort derrière un Nginx configuré en LoadBalancer. Maintenant que vous savez ça, on peut y aller.

Le Deployment

On va commencer par balancer le Yaml qui marche :
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nextcloud-deployment
spec:
  selector:
    matchLabels:
      app: nextcloud
  replicas: 1
  template:
    metadata:
      labels:
        app: nextcloud
    spec:
      containers:
      - name: nginx
        image: nginx:1.15
        ports:
        - containerPort: 80
        volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
        - name: pv-nextcloud
          mountPath: /var/www/html
        lifecycle:
          postStart:
            exec:
             command: ["bin/sh", "-c", "mkdir -p /var/www/html"]
      - name: nextcloud
        image: nextcloud:14.0-fpm
        ports:
        - containerPort: 9000
        volumeMounts:
        - name: pv-nextcloud
          mountPath: /var/www/html
        resources:
          limits:
            cpu: "1"
      volumes:
      - name : nginx-config
        configMap:
           name: nginx-config
      - name: pv-nextcloud
        flexVolume:
          driver: ceph.rook.io/rook
          fsType: ceph
          options:
            fsName: myfs
            clusterNamespace: rook-ceph
            path: /nextcloud2

Il n'y a pas le Service associé pour la simple et bonne raison que chacun fait comme il le veut. Si vous êtes chez DigitalOcean, OVH ou chez un des GAFAM qui propose du k8s, vous aurez un LoadBalancer qui va bien. Si vous êtes comme moi, vous êtes réduit à faire du NodePort.

Ce qu'il faut comprendre

Vous remarquerez qu'il y a deux conteneurs : Nginx et Nextcloud-FPM. Nginx écoute sur le port 80 et va router le trafic à travers vers le port 9000 du conteneur de Nextcloud.

Nginx

      - name: nginx
        image: nginx:1.15
        ports:
        - containerPort: 80
        volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
        - name: pv-nextcloud
          mountPath: /var/www/html
        lifecycle:
          postStart:
            exec:
             command: ["bin/sh", "-c", "mkdir -p /var/www/html"]
On va faire gober à Nginx deux points de montage : sa configuration et les sources de Nextcloud. Sans les sources de l'application, Nginx ne pourra pas avoir accès aux fichiers PHP, et ne servira donc à rien. On va donc prendre le point de montage originalement dédié à Nextcloud pour le monter une deuxième fois dans un deuxième conteneur, celui de Nginx.

Lifecycle

Remarquez la présence de la section lifecycle, elle permet d’exécuter ce que vous voulez au démarrage du conteneur. Quand j'apprenais à me servir de ce couple, je ne comprenais pas pourquoi Nginx ne voulait pas correctement fonctionner. J'ai passé du temps à comprendre que le conteneur Nginx et le conteneur Nextcloud n'avaient pas le même docRoot :
  • Nginx : /srv/html
  • Nextcloud : /var/www/html
Comprenez que les requêtes Nginx allaient chercher des fichiers dans /srv/html/blabla.php quand Nextcloud annonçait la présence de ses sources dans /var/www/html/blabla.php. Le bordel.

C'est là que je n'ai trouvé pas idiot l'idée de créer le chemin manquant au démarrage du pod avec un postStart. Du coup, j'avais Nginx et Nextcloud au diapason. Il est sans doute possible de configurer Nginx pour surcharger son docRoot, mais c'était l'occasion de jouer avec des commandes en amont de la création d'un conteneur.

Les deux points de montage

On a donc un point de montage pour les sources de Nextcloud :
        - name: pv-nextcloud
          mountPath: /var/www/html
Et un point de montage pour la configuration de Nginx :
        - name: nginx-config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf

Là aussi, j'ai perdu un peu de temps avant de comprendre qu'il fallait balancer toute la configuration de Nginx et pas seulement ce que j'ai l'habitude de mettre dans les sites-enabled. C'est du moins à faire quand on écrase le nginx.conf du pod. En y réfléchissant, c'est sans doute plus simple de modifier le point montage pour n'ajouter qu'un fichier dans le fameux sites-enabled.

Pour gérer la configuration de Nginx, je passe par une ConfigMap :
kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-config
data:
  nginx.conf: |
    worker_processes  1;

    error_log  /var/log/nginx/error.log warn;
    pid        /var/run/nginx.pid;

    events {
        worker_connections  1024;
    }

    http {
        include       /etc/nginx/mime.types;
        default_type  application/octet-stream;

        log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" "$http_x_forwarded_for"';

        access_log  /var/log/nginx/access.log  main;

        sendfile        on;
        #tcp_nopush     on;

        keepalive_timeout  65;

        #gzip  on;

        server {
            listen 80;

            add_header X-Content-Type-Options nosniff;
            add_header X-XSS-Protection "1; mode=block";
            add_header X-Robots-Tag none;
            add_header X-Download-Options noopen;
            add_header X-Permitted-Cross-Domain-Policies none;
            add_header Referrer-Policy no-referrer;

            root /var/www/html;

            location = /robots.txt {
                allow all;
                log_not_found off;
                access_log off;
            }

            location = /.well-known/carddav {
                return 301 $scheme://$host/remote.php/dav;
            }
            location = /.well-known/caldav {
                return 301 $scheme://$host/remote.php/dav;
            }

            # set max upload size
            client_max_body_size 10G;
            fastcgi_buffers 64 4K;

            # Enable gzip but do not remove ETag headers
            gzip on;
            gzip_vary on;
            gzip_comp_level 4;
            gzip_min_length 256;
            gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
            gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;

            location / {
                rewrite ^ /index.php$request_uri;
            }

            location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)/ {
                deny all;
            }
            location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) {
                deny all;
            }

            location ~ ^/(?:index|remote|public|cron|core/ajax/update|status|ocs/v[12]|updater/.+|ocs-provider/.+)\.php(?:$|/) {
                fastcgi_split_path_info ^(.+\.php)(/.*)$;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info;
                # fastcgi_param HTTPS on;
                #Avoid sending the security headers twice
                fastcgi_param modHeadersAvailable true;
                fastcgi_param front_controller_active true;
                fastcgi_pass 127.0.0.1:9000;
                fastcgi_intercept_errors on;
                fastcgi_request_buffering off;
            }

            location ~ ^/(?:updater|ocs-provider)(?:$|/) {
                try_files $uri/ =404;
                index index.php;
            }

            # Adding the cache control header for js and css files
            # Make sure it is BELOW the PHP block
            location ~ \.(?:css|js|woff|svg|gif)$ {
                try_files $uri /index.php$request_uri;
                add_header Cache-Control "public, max-age=15778463";
                add_header X-Content-Type-Options nosniff;
                add_header X-XSS-Protection "1; mode=block";
                add_header X-Robots-Tag none;
                add_header X-Download-Options noopen;
                add_header X-Permitted-Cross-Domain-Policies none;
                add_header Referrer-Policy no-referrer;

                # Optional: Don't log access to assets
                access_log off;
            }

            location ~ \.(?:png|html|ttf|ico|jpg|jpeg)$ {
                try_files $uri /index.php$request_uri;
                # Optional: Don't log access to other assets
                access_log off;
            }
        }

    }
Eh oui, il y a tout dedans. Ça déforme l'affichage de ce billet, m'enfin. C'est une configuration Nginx classique.

On peut quand même s'arrêter sur la configuration du fastcgi_pass : il tape sur le 127.0.0.1 et le port 9000 du conteneur Nextcloud. Je n'ai pas encore gratté pour comprendre le pourquoi du comment mais je suppose que les deux conteneurs tournant dans le réseau du pod, ils se comportent comme deux services dans une seule et même machine. À confirmer.

On apply tout ça

Attention ! Avant de balancer le Deployment, balancez le yaml de la ConfigMap. Sans ça, Nginx ne chargera pas votre configuration !
dada@k8smaster1:~$ kubectl apply -f configmap.yaml
dada@k8smaster1:~$ kubectl apply -f nextcloud.yaml
Si tout se passe bien, vous devriez pouvoir voir ça :
dada@k8smaster1:~$ kubectl get pods
nextcloud-deployment-d6cbb8446-87ckf   2/2     Running   0          15h
Remarquez que Kubernetes vous montre bien qu'il y a deux conteneurs dans ce pod : 2/2.

Pour aller plus loin

Je ne parle pas des vérifications de l'état des conteneurs. Il faudrait placer des sondes liveness et readness pour parfaitement vérifier l'état des conteneurs. Sans ça, si l'un des services tombe, Kubernetes ne sera pas forcément en mesure de le détecter et de relancer le pod.
Il est aussi possible, pour respecter le concept de micro-service, de ne pas concaténer deux conteneurs dans un seul pod mais de faire un pod par conteneur et des services associés. Ça demande plus de travail pour un résultat qui, dans mon cas, n'apporte pas grand chose.

Installer Collabora Online avec Nextcloud

Rédigé par dada / 05 avril 2017 / 19 commentaires




Le soleil repointe le bout de son nez et je ne trouve plus le temps de sortir des billets. L'apéro passe avant tout mais malgré ça, j'ai quand même pas mal joué avec mon serveur.
D'abord, j'ai changé de crémerie, encore, pour laisser tomber mon C1 chez Scaleway pour une Kimsufi aux caractéristiques bien plus rigolotes : adieu l'ARM, coucou le Core i3. Ça m'a permis de mettre en place l'objet de ce billet : Collabora Online dans Nextcloud via Docker !

je présuppose que votre machine tourne sous Debian Jessie (what else ?) avec Nextcloud 11.0.2.

Installer Docker

Je suis passé par l'installation de Docker CE. Ça permet d'avoir une version plus récentes de la bête.

On commence par les dépendances qui vont bien :
apt-get install apt-transport-https ca-certificates curl software-properties-common 
On enchaîne sur la clé GPG du dépôt :
curl -fsSL https://download.docker.com/linux/debian/gpg | apt-key add -
On ajoute le dépôt dan le sources.list :
add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/debian $(lsb_release -cs) stable" 
Pour finir, on installe notre nouveau jouet et c'est parti !
apt-get update && apt-get install docker-ce

Mise en place du conteneur de Collabora

On le télécharge :
docker pull collabora/code 
On le lance :
docker run -t -d -p 127.0.0.1:9980:9980 -e 'domain=votre\\.instance\\.com' --restart always --cap-add MKNOD collabora/code 
C'est pendant cette étape que je me suis le plus pris la tête... Ils disent de lancer docker avec pour paramètre un sous-domaine pour Collabora alors qu'il ne le faut pas, pas chez moi du moins. En fait, comme Collabora tourne sur le même serveur que mon instance, pas besoin de sous-domaine.

Configurer votre Vhost

Pour Nginx, ajoutez ces lignes dans votre vhost : (snippet ici).

    # static files     
    location ^~ /loleaflet {
        proxy_pass https://127.0.0.1:9980;
        proxy_set_header Host $http_host;
    }       
    # WOPI discovery URL
        location ^~ /hosting/discovery {
        proxy_pass https://127.0.0.1:9980;
        proxy_set_header Host $http_host;    
    }        
    # websockets, download, presentation and image upload
    location ^~ /lool {        
        proxy_pass https://127.0.0.1:9980;
        proxy_set_header Upgrade $http_upgrade;  
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;
   }
Pour Apache2. c'est trop long alors cliquez sur snippet !

Et voilà pour le plus chiant !

Activer Collabora

Maintenant, pour terminer, allez donc activer l'application en la configurant avec le sous-domaine de votre instance : https://votre.instance.com. Pensez bien à cliquer sur "Appliquer" si vous ne voulez pas risquer de devenir chèvre...

Tous ces efforts vous permettront de cliquer paisiblement sur ces 3 nouvelles options :



Amusez-vous bien !

Partage de fichiers dans un réseau Windows

Rédigé par dada / 02 septembre 2016 / 11 commentaires


Réussir à partager des fichiers dans un environnement Windows semble simple, on installe Samba et c'est plié. J'ai pourtant rencontré trop de problèmes avec cette solution, j'ai lâché l'affaire et je me suis creusé le crâne. Ma situation est la suivante :
  • Un serveur destiné à partager des fichiers chez un hébergeur sous Debian
  • Un réseau familial sous Windows
  • Un besoin basique de sécurité
  • Un besoin de fiabilité
  • Une solution éprouvée
Je gère le serveur sous Debian sans problème. Je m'y connecte déjà en SSH et une paire de clés privée/publique avec un point de montage dans mon Nautilus. Y'a rien à ajouter, ça comble les besoins de sécurité.

Le réseau familial, j'ai absolument pas envie de me prendre la tête avec samba et sa configuration affreusement chiante. J'ai choisi un truc de feignant : Apache. Comme ça, pas de prise de tête, tout se fait via le navigateur. Pourquoi Apache ? Parce que je vais ajouter une pièce dans tout ce merdier : une Raspberry Pi première génération.
L’idée qui m'a traversé l'esprit est la suivante : faire un montage SSHFS sur une Raspberry Pi qui sera la seule à pouvoir se connecter au serveur et qui offrira son contenu aux membres du réseau via une IP privée. L’accès aux données distantes se fait via SSH et Apache s'occupe du reste dans l'unique boucle locale. Note importante : seul celui que a un accès au serveur peut partager des données. Tout se fait en sens unique.

Avec un schéma, ça donne ça :



Le dessin est mauvais, mais l’idée est là : un accès en sens unique pour les PC sous Windows via Firefox. Pour que tout ça tourne bien, il ne faut pas grand chose :
  • Une Raspberry Pi avec Raspbian, un utilisateur avec SSH et une IP fixe
  • Un serveur Apache tournant avec les droits group/user dudit utilisateur pour justement éviter les problèmes de droits (envvars).
  • Un point de montage SSHFS automatique dans le fstab si redémarrage intempestif il y a, et ça arrive toujours. Toujours
  • Un Vhost qui pointe vers ce point de montage
  • Un peu de temps
On se trouve donc avec une installation pas si simple que ça, quoique, mais qui aura le mérite de faire ce que je lui demande dans des conditions honorables. Après, en tant que DevOps (*rire*), je jongle avec ce que je sais faire de mieux : des serveurs, du SSH, de l'Apache et Debian.

Si vous avez des idées plus simples et aussi stables, je suis preneur. Je ne promets pas de les appliquer tout de suite, mais ça sera stocké quelque part.

Ah, et pour finir, je vais essayer de trouver un moyen de rendre l'affichage des fichiers partagés un peu moins laid  parce que le listing du contenant d'un répertoire est vraiment limite sous Apache.
Je me suis bien amusé à faire ça. J’espère que ça va vraiment tenir. Au final, je m’inquiète plus pour ma Raspberry Pi qui traîne en équilibre sur une Freebox que du bon fonctionnement de l'installation ;-)
 

Apache2 et mod_deflate : soulager votre serveur

Rédigé par dada / 21 octobre 2014 / 7 commentaires


Lorsqu'on s’héberge, on s'adapte aux capacités de son serveur et de sa ligne. J'ai commencé ce blog chez moi, sur une ligne Free pour particulier.

A l’époque, même s'il n’était pas monstrueux, mon serveur était un Intel Core 2 Duo plus que correct couplé à 2Go de Ram. Par contre, ma ligne ADSL me limitait lourdement : 128ko/s en upload, seulement. Et c’était le débit maximum si personne d'autre que moi ne traînait sur la machine.

En accord avec cette configuration, je me servais du mod_deflate pour qu'Apache compresse mes pages web avant de les envoyer sur la toile. Le processeur bossait dur et le débit montant respirait. Une page compressée prend moins de place dans les tuyaux, du coup, plus de gens peuvent y avoir accès.

En prenant un VPS chez Pulseheberg, j'ai complètement changé de configuration. Au revoir la limite de bande passante et bienvenue dans le monde des tout petits processeurs ARM. Le besoin de compresser les pages a disparu. Plus besoin du mod_deflate, mais je l'avais quand même ajouté par réflexe, habitude.

C'est en le faisant sauter, en le désactivant tout simplement que j'ai franchement gagné en réactivité. Le processeur ne bossant plus pour compresser mon contenu, la navigation sous ownCloud ou sous FreshRSS est devenue bien plus fluide.

Voici rapidement comment le faire sauter si vous ne savez pas s'il est activé :

Connectez-vous et tapez la commande suivante :

# a2dismod


Vous devriez voir ceci s'afficher :

# Your choices are: alias auth_basic authn_file authz_default authz_groupfile authz_host authz_user autoindex cgi dir env mime negotiation php5 reqtimeout setenvif ssl status mod_deflate
Which module(s) do you want to disable (wildcards ok)?


Rentrez mod_deflate pour le désactiver et le tour est joué.

Edit : les commentaires me signalent une boulette. C'est "deflate" qu'il faut rechercher et non "mod_deflate" :)

Si vous êtes dans la même situation que moi, vous devriez sentir la différence ! :-)