Am imagini dockerizate cu redis (ca ghiduri oficiale dockerhub atunci când utilizați redis.conf personalizat) și imagine personalizată (pe baza imaginii alpine, vezi aici: https://pastebin.com/9WsMk1JC ) de sentinel (tot cu sentinel.conf personalizat).
În redis.conf, acești trei parametri au fost adăugați (restul rămâne ca fișier de configurare implicit):
parola masterauth
utilizator principal implicit
requirepass parola
În sentinelă.conf, din cauza separării instanței redis (alte containere) și sentinel este configurat pentru a porni cu un master inexistent pe localhost. Am adăugat parametri pentru a efectua autentificarea pe master. Deci, fișierul de configurare are doi parametri suplimentari (repausul rămâne ca fișier de configurare implicit):
sentinel auth-pass parola mymaster
sentinel auth-user mymaster implicit
După ce containerul redis este pornit și gata pentru conexiuni, pornesc imaginea sentinelă, când termin, mă conectez la redis CLI pe portul sentinel și comut manual manual:
redis-cli -p 26379 sentinel remove mymaster && redis-cli -p 26379 sentinel monitor mymaster <redis container ip> 6379 2
CLI-ul sentinelului revine OK de două ori, dar după un timp se imprimă că masterul este oprit. Și rămâne în acest statut pentru totdeauna.
Conectivitate între containere testată prin telnet și ping - OK.
Bănuiesc că redis sentinel nu se poate conecta la master - din cauza parolei.
De ce?
- Replicile containerului redis - realizarea de câteva copii de imagine care rulează și unirea lor în MASTER-SLAVE prin CLI funcționează ca un farmec. Containerele pot vorbi între ele folosind parola de la redis.conf.
- Înainte de a introduce parole la redis contieners, sentinelele se puteau conecta și efectua failover-uri cu succes.
- A lucrat pe Openshift fără configurarea parolei.