2017-09-07 1 views
0

J'essaie de configurer les conteneurs GitLab, Redis et PostgreSQL dans Kubernetes en utilisant Gluster pour la persistance. Les nœuds GlusterFS sont configurés sur des machines (CentOS) externes au cluster Kubernetes (s'exécutant sur l'hôte RancherOS). Le problème est que lorsque GitLab essaie de démarrer, la page de connexion ne se charge pas. C'est une configuration fraîche et pas quelque chose qui a cessé de fonctionner maintenant.Redis db problème d'autorisation lors de l'exécution GitLab

[email protected]:/var/log/gitlab/gitlab# tail -50 sidekiq.log 
... 
... 
    2017-09-07T11:53:03.098Z 547 TID-1fdjck ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/sidekiq-5.0.0/lib/sidekiq/processor.rb:84:in `process_one' 
2017-09-07T11:53:03.098Z 547 TID-1fdjck ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/sidekiq-5.0.0/lib/sidekiq/processor.rb:73:in `run' 
2017-09-07T11:53:03.098Z 547 TID-1fdjck ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/sidekiq-5.0.0/lib/sidekiq/util.rb:17:in `watchdog' 
2017-09-07T11:53:03.098Z 547 TID-1fdjck ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/sidekiq-5.0.0/lib/sidekiq/util.rb:26:in `block in safe_thread' 
2017-09-07T11:53:03.099Z 547 TID-1fdf1k ERROR: Error fetching job: ERR Error running script (call to f_7b91ed9f4cba40689cea7172d1fd3e08b2efd8c9): @user_script:7: @user_script: 7: -MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error. 
2017-09-07T11:53:03.100Z 547 TID-1fdf1k ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis/client.rb:121:in `call' 
2017-09-07T11:53:03.100Z 547 TID-1fdf1k ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/peek-redis-1.2.0/lib/peek/views/redis.rb:9:in `call' 
2017-09-07T11:53:03.100Z 547 TID-1fdf1k ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis.rb:2399:in `block in _eval' 
2017-09-07T11:53:03.100Z 547 TID-1fdf1k ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis.rb:58:in `block in synchronize' 
2017-09-07T11:53:03.100Z 547 TID-1fdf1k ERROR: /usr/lib/ruby/2.3.0/monitor.rb:214:in `mon_synchronize' 
2017-09-07T11:53:03.100Z 547 TID-1fdf1k ERROR: /home/git/gitlab/vendor/bundle/ruby/2.3.0/gems/redis-3.3.3/lib/redis.rb:58:in `synchronize' 
... 

J'ai donc vérifié les bûches de conteneurs Redis.

[[email protected] ~]# docker logs -f 67d44f585705 
... 
... 
[1] 07 Sep 14:43:48.140 # Background saving error 
[1] 07 Sep 14:43:54.048 * 1 changes in 900 seconds. Saving... 
[1] 07 Sep 14:43:54.048 * Background saving started by pid 2437 
[2437] 07 Sep 14:43:54.053 # Failed opening .rdb for saving: Permission denied 
... 

Vérifié en ligne pour cette question et les autorisations suivantes remarqué et les détails du propriétaire à l'intérieur de la nacelle Redis:

[[email protected] ~]# docker exec -it 67d44f585705 bash 
groups: cannot find name for group ID 2000 
[email protected]:/# ls -ld /var/lib/redis/ 
drwxr-sr-x 12 1000 1000 8192 Sep 7 11:51 /var/lib/redis/ 
[email protected]:/# 
[email protected]:/# ls -l /var/lib/redis/ 
total 22 
drwxr-sr-x 2 1000 1000  6 Sep 6 10:37 backups 
drwxr-sr-x 2 1000 1000  6 Sep 6 10:37 builds 
drwxr-sr-x 2 redis redis  6 Sep 6 10:14 data 
-rw-r--r-- 1 redis redis 13050 Sep 7 11:51 dump.rdb 
-rwxr-xr-x 1 redis redis 21 Sep 5 11:00 index.html 
drwxrws--- 2 1000 1000  6 Sep 6 10:37 repositories 
drwxr-sr-x 5 1000 1000 55 Sep 6 10:37 shared 
drwxr-sr-x 2 root root 8192 Sep 6 10:37 ssh 
drwxr-sr-x 3 redis redis 70 Sep 7 10:20 tmp 
drwx--S--- 2 1000 1000  6 Sep 6 10:37 uploads 
[email protected]:/# 
[email protected]:/# grep 1000 /etc/passwd 
[email protected]:/# 

Ran suivantes et à toutes l'air bien.

[email protected]:/# chown redis:redis -R /var/lib/redis/ 

Cependant, quand je supprimé et couru à nouveau le déploiement YAML gitlab ce, les droits à l'intérieur du conteneur Redis à nouveau mais j'ai biaisé vers le haut. Je ne suis pas sûr si Gluster est en train de bousiller avec les autorisations de fichiers/dossiers Redis. Je ne peux pas penser à une autre raison pour le moment.

Une chose que je voudrais souligner est que tous les trois conteneurs utilisent le même PVC

- name: gluster-vol1 
    persistentVolumeClaim: 
    claimName: gluster-dyn-pvc 

Au-dessus est commun pour tous les trois. Ce qui diffère est indiqué ci-dessous:

a) postgresql-deployment.yaml 

volumeMounts: 
- name: gluster-vol1 
    mountPath: /var/lib/postgresql 

b) redisio-deployment.yaml 

volumeMounts: 
- name: gluster-vol1 
    mountPath: /var/lib/redis 

c) gitlab-deployment.yaml 

volumeMounts: 
- name: gluster-vol1 
    mountPath: /home/git/data 

Une suggestion?

+0

De même, est-ce la bonne façon d'utiliser la même 'classe de stockage' pour les trois conteneurs ou dois-je changer quelque chose? – Technext

+0

Pouvez-vous afficher la sortie 'describe pvc gluster-vol1'? – whites11

+0

J'ai eu une erreur lors de l'exécution de la commande ci-dessus. Lorsque vous utilisez 'gluster-dyn-pvc' au lieu de' gluster-vol1', cela fonctionne. Sortie collée [ici] (https://pastebin.com/rysEhHP4) – Technext

Répondre

0

les étapes suivantes, j'ai pu résoudre le 'Permission denied' problème pour Redis:

  1. créé des volumes séparés pour PostegreSQL, Redis et gitlab ce à GlusterFS.
  2. Classe de stockage distincte créée pour les trois.
  3. Créé PersistanceVolumeClaim (PVC) pour eux et mappé /var/lib/postgresql, /var/lib/redis et /home/git/data à leurs PVC respectifs.

Auparavant, les trois chemins mentionnés précédemment pointaient vers le même volume dans GlusterFS. D'une manière ou d'une autre, il semble qu'ils aient causé des problèmes à Redis.