ویونیکس
گفت‌وگو با کارشناس
← شروع آموزش

WIUNIX ACADEMY

آموزش نصب Redis Sentinel در اوبونتو و دبیان

صفحهٔ 2 از 7؛ مراحل قبلی و پیش‌نیازها را پیش از ادامه مرور کن.

آموزش متناسب با محیط تو

کجا اجرا می‌کنی؟

سیستم‌عامل و نسخه را انتخاب کن تا مراحل، دستورها و راه‌حل‌ها برای همان محیط نمایش داده شوند.

Debian 13بررسی‌شده با مستندات رسمی ·

آموزش متناسب با مقادیر تو

تنظیمات این آموزش

مقادیر نمونه را برای محیط خودت تنظیم کن؛ متن و دستورهای مرتبط با هم تغییر می‌کنند. رمز، کلید خصوصی و توکن وارد نکن. مقادیر فقط در همین زبانه نگهداری می‌شوند و به سرور یا لینک اشتراک‌گذاری فرستاده نمی‌شوند. پیش از اجرا، DNS، گواهی‌ها و سیاست شبکهٔ واقعی را بررسی کن.

آی‌پی، دامنه یا پورت مثال‌ها با محیط تو فرق دارد؟ دکمهٔ زیر را باز کن، مقادیر را تغییر بده و «اعمال در آموزش» را بزن؛ سپس دستورهای به‌روز‌شده را کپی کن.

تنظیم مقادیر برای محیط من5 مقدار قابل‌تغییر
03

قدم بعدی

توقف نمونهٔ تازه و نگهداری تنظیمات اولیه

فقط روی سرورهای تازهٔ همین آموزش انجام شود؛ توقف Redis محیط عملیاتی مجاز نیست. نسخهٔ تنظیمات با ساختار مسیر نگهداری می‌شود. نبودن هر کدام از فایل‌ها خطاست. این آرشیو محرمانه است و نباید وارد گیت یا فضای عمومی شود.

Bash
sudo systemctl stop redis-sentinel redis-server
sudo bash -eu <<'BACKUP'
umask 077
test -f /etc/redis/redis.conf
test -f /etc/redis/sentinel.conf
install -d -m 0700 /root/academy-backups
backup=$(mktemp -d /root/academy-backups/redis-defaults-XXXXXXXX)
tar -C / -cpf "$backup/etc-redis.tar" etc/redis
tar -tf "$backup/etc-redis.tar" >/dev/null
tar -C / -df "$backup/etc-redis.tar"
printf 'Defaults retained: %s\n' "$backup"
BACKUP
از کجا بدانم درست انجام شد؟

دو سرویس اختصاصی متوقف‌اند و آرشیو تنظیمات خوانده و با منبع تطبیق داده شده است.

04

قدم بعدی

گواهی مستقل برای هر سرور

زیرساخت گواهی مورد اعتماد باید از قبل سه فایل ورودی را در مسیر محافظت‌شده گذاشته باشد. هر سرور کلید و گواهی جداگانه، SAN مطابق IP خصوصی خودش، کاربردهای serverAuth و clientAuth و زنجیرهٔ معتبر داشته باشد. کلید خصوصی CA به سرورها منتقل نشود و یک کلید برای سه سرور تکرار نشود. برای میزبان مدیر و اپلیکیشن هم گواهی کلاینت جدا صادر شود. mTLS اعتماد به CA را بررسی می‌کند و جای نام کاربری ACL را نمی‌گیرد. اعتبارسنجی CA در اتصال داخلی Redis و Sentinel را نباید بررسی نام میزبان نامید. CA اختصاصی این سامانه، مسیر خصوصی و محدودیت مبدأ لازم‌اند؛ کلاینتی که تطبیق نام مقصد می‌خواهد باید آن را صریح پشتیبانی و بررسی کند.

Bash
(
set -euo pipefail
sudo install -d -o root -g redis -m 0750 /etc/redis/tls
sudo install -o root -g redis -m 0640 /root/academy-pki/ca.pem /etc/redis/tls/ca.pem
sudo install -o root -g redis -m 0640 /root/academy-pki/node-fullchain.pem /etc/redis/tls/node.pem
sudo install -o root -g redis -m 0640 /root/academy-pki/node-key.pem /etc/redis/tls/node.key
sudo openssl verify -CAfile /etc/redis/tls/ca.pem -purpose sslserver /etc/redis/tls/node.pem
sudo openssl verify -CAfile /etc/redis/tls/ca.pem -purpose sslclient /etc/redis/tls/node.pem
sudo openssl x509 -in /etc/redis/tls/node.pem -noout -dates -ext subjectAltName
sudo openssl x509 -in /etc/redis/tls/node.pem -checkend 604800 -noout
sudo openssl x509 -in /etc/redis/tls/node.pem -pubkey -noout | openssl sha256
sudo openssl pkey -in /etc/redis/tls/node.key -pubout | openssl sha256
sudo -u redis test -r /etc/redis/tls/node.key
)
از کجا بدانم درست انجام شد؟

هر دو کاربرد گواهی معتبر است، SAN درست است، هش کلید عمومی برابر است و کاربر redis کلید را می‌خواند.

شش اعتبارنامه با مسئولیت جدا

در مدیر اسرار موجود، برای شش نقش رمزهای مستقل۶۴ نویسه‌ای هگز بسازید: ADMIN برای نگهداری، APP برای GET و SET و WAIT و بررسی سلامت و نقش در فضای academy:*، REPL برای تکثیر، CONTROL برای کنترل Redis توسط Sentinel، PEER برای ارتباط مدیریتی Sentinelها و DISCOVERY برای خواندن نشانی سرور اصلی. رمز هر نقش روی سه سرور یکسان است، اما بین نقش‌ها مشترک نباشد. عبارت‌های REPLACE_* نمونه‌اند و باید داخل ویرایشگر محافظت‌شده عوض شوند، نه در آرگومان فرمان. ضبط ترمینال و رهگیری شل هنگام ویرایش اسرار خاموش باشد. نمایش عمومی ACL و فایل تنظیمات هم امن نیست. رمز اتصال خروجی در تنظیمات محافظت‌شده لازم است؛ هش‌کردن ACL ورودی این نیاز را حذف نمی‌کند.

05

قدم بعدی

ویرایش فایل دسترسی Redis

روی هر سه سرور انجام شود. پنل بعد محتوای فایل است و فرمان شل نیست. چهار رمز نمونه را پیش از ذخیره عوض کنید. کاربر پیش‌فرض غیرفعال است. اپلیکیشن دسترسی Pub/Sub، به‌ویژه کانال رزروشدهٔ Sentinel، ندارد. مدیر اختیار نگهداری دارد ولی دسترسی اولیهٔ کانال ندارد؛ فقط CONTROL کانال داخلی را می‌گیرد.

Bash
sudo install -o root -g redis -m 0640 /dev/null /etc/redis/users.acl
sudo nano /etc/redis/users.acl
از کجا بدانم درست انجام شد؟

فایل محافظت‌شده برای محتوای ACL آماده است.

محتوای ACL سرور داده

محتوای یکسان روی A و B و C. حساب REPL با وجود نداشتن فرمان خواندن کلید، جریان کامل داده را دریافت می‌کند و رمز آن محرمانه است. CONTROL می‌تواند نقش سرور را تغییر دهد و تنظیمات را بازنویسی کند؛ این حساب برای اپلیکیشن نیست. دسترسی عمومی کانال به APP یا REPL داده نشود.

Redis ACL · /etc/redis/users.acl
user default off
user admin on >REPLACE_ADMIN_64_HEX ~* resetchannels +@all
user app on >REPLACE_APP_64_HEX ~academy:* resetchannels -@all +ping +role +get +set +wait
user repl on >REPLACE_REPL_64_HEX resetchannels -@all +ping +replconf +psync
user control on >REPLACE_CONTROL_64_HEX resetchannels &__sentinel__:hello -@all +multi +slaveof +ping +exec +subscribe +config|rewrite +role +publish +info +client|setname +client|kill +script|kill
06

قدم بعدی

تنظیم Redis با امکان بازنویسی نقش

روی سه سرور، فایل بسته با تنظیمات اختصاصی پنل بعد جایگزین شود. نشانی محلی A همان10.20.0.10 است؛ در B هر دو مقدار bind و announce به10.20.0.11 و در C به10.20.0.12 تغییر کند. رمز REPL با ACL برابر باشد و روی A هم تنظیم شود تا پس از جابه‌جایی بتواند نسخهٔ دریافت‌کننده شود. فایل باید برای بازنویسی نقش توسط Sentinel قابل نوشتن بماند. نسخهٔ اولیهٔ بسته را حفظ کنید.

Bash
sudo nano /etc/redis/redis.conf
از کجا بدانم درست انجام شد؟

نشانی محلی درست و رمز تکثیر آماده شده‌اند.

محتوای تنظیمات و بودجهٔ حافظه

حد۲۵۶ مگابایت فقط برای آزمایش کوچک است. حافظهٔ جدا برای پردازش، بافر کلاینت، تکثیر و کپی هنگام ذخیره‌سازی لازم است. سیاست noeviction به‌جای حذف کلید، نوشتن جدید را رد می‌کند. شرط یک نسخهٔ همراه، بخشی از نوشتن روی سرور جداافتاده را پس از۱۰ ثانیه محدود می‌کند؛ حصار فوری یا تضمین نبود اتلاف نیست. وجود سه سرور داده باعث می‌شود پس از خرابی یک میزبان، نویسندهٔ تازه هنوز یک نسخهٔ دریافت‌کننده داشته باشد. با فقط دو سرور داده، همین سیاست تا بازگشت سرور دیگر نوشتن را متوقف می‌کند.

Redis configuration · /etc/redis/redis.conf
bind 127.0.0.1 10.20.0.10
protected-mode yes
port 0
tls-port 6379
tls-cert-file /etc/redis/tls/node.pem
tls-key-file /etc/redis/tls/node.key
tls-ca-cert-file /etc/redis/tls/ca.pem
tls-auth-clients yes
tls-protocols "TLSv1.2 TLSv1.3"
tls-replication yes
daemonize no
supervised systemd
pidfile /run/redis/redis-server.pid
logfile /var/log/redis/redis-server.log
dir /var/lib/redis
dbfilename dump.rdb
save 900 1
appendonly yes
appendfsync everysec
maxmemory 256mb
maxmemory-policy noeviction
aclfile /etc/redis/users.acl
masteruser repl
masterauth REPLACE_REPL_64_HEX
replica-announce-ip 10.20.0.10
replica-announce-port 6379
replica-read-only yes
replica-serve-stale-data no
min-replicas-to-write 1
min-replicas-max-lag 10

مبدأ اولیه فقط برای B و C

فقط در B و C این خط به همان فایل تنظیمات اضافه شود. در راه‌اندازی اولیه، A نباید این خط را داشته باشد. پس از جابه‌جایی، نقش و نشانی بازنویسی‌شده را Sentinel مدیریت می‌کند؛ اجرای دوبارهٔ فایل اولیه می‌تواند توپولوژی درست را خراب کند.

Redis configuration · /etc/redis/redis.conf — append only on B/C
replicaof 10.20.0.10 6379
همهٔ آموزش‌های آکادمی ↗