دان موزیک  ,ثبت شركت  ,طلاق توافقي  ,خريد پرفكت مانى  ,خیریه سگال  ,بازی اندروید  ,گیربکس اتوماتیک  ,خرید از بانه  ,صنایع دستی اصفهان  ,میناکاری  ,ویبره  ,خرید دامنه  ,اخبار روز  ,
server .

server

نحوه استفاده از Ansible براي نصب و راه اندازي وردپرس با LAMP در اوبونتو 18.04

مقدمه
اتوماسيون سرور مجازي اكنون به دليل ماهيت يكبار مصرف محيط هاي كاربردي مدرن ، نقش اساسي در مديريت سيستم ها ايفا مي كند. ابزارهاي مديريت پيكربندي مانند Ansible معمولاً براي ساده سازي فرايند خودكار سازي تنظيم سرور مجازي با تعيين مراحل استاندارد براي سرور مجازي جديد استفاده مي شود و در عين حال خطاي انساني مرتبط با تنظيمات دستي را نيز كاهش مي دهد.
Ansible يك معماري ساده را ارائه مي دهد كه نيازي به نصب نرم افزار ويژه روي گره ها ندارد. همچنين مجموعه اي از ويژگي ها و ماژول هاي داخلي را فراهم مي كند كه نوشتن اسكريپت هاي اتوماسيون را تسهيل مي كند.
در اين راهنما نحوه استفاده از Ansible براي خودكارسازي مراحل موجود در راهنماي ما درباره نحوه نصب وردپرس با LAMP در اوبونتو 18.04 توضيح داده شده است. وردپرس محبوب ترين CMS (سيستم مديريت محتوا) در اينترنت است كه به كاربران امكان مي دهد وبلاگ ها و وب سايتهاي قابل انعطاف را فراتر از MySQL با پردازش PHP تنظيم كنند. پس از راه اندازي ، تقريباً تمام مراحل اجرا از طريق web frontend قابل انجام است.
پيش نيازها
براي اجراي تنظيم خودكار ارائه شده توسط playbook  كه در اين راهنما در مورد آن صحبت مي كنيم ، به اين موارد نياز داريد:
• يك گره كنترل Ansible : يك دستگاه اوبونتو 18.04 كه داراي Ansible نصب شده و تنظيم شده است تا با استفاده از كليدهاي SSH به ميزبان هاي Ansible شما متصل شود. اطمينان حاصل كنيد كه گره كنترل داراي يك كاربر معمولي با مجوزهاي sudo باشد و فايروال فعال نيز داشته باشد ، همانطور كه در راهنماي راه اندازي سرور مجازي اوليه ما توضيح داده شده است. براي تنظيم Ansible ، لطفا راهنماي ما در مورد نحوه نصب و پيكربندي Ansible در اوبونتو 18.04 را دنبال كنيد.
• يك يا چند هاست Ansible: يك يا چند سرور مجازي از راه دور Ubuntu 18.04 كه قبلاً به كمك راهنماي نحوه استفاده از Ansible براي خودكارسازي تنظيمات اوليه سرور مجازي در اوبونتو 18.04 تنظيم شده اند.
قبل از ادامه كار ، ابتدا بايد اطمينان حاصل كنيد كه گره كنترل Ansible شما قادر به اتصال و اجراي دستورات در هاست (هاي) Ansible باشد. براي بررسي اتصال ، لطفاً مرحله 3 نحوه نصب و پيكربندي Ansible در اوبونتو 18.04 را بررسي كنيد.

اين Playbook چه كاري انجام مي دهد؟
اين playbook  Ansible از طريق روشي كه در راهنماي ما در مورد نحوه نصب وردپرس با LAMP در اوبونتو 18.04 ارائه شده است ، جايگزيني براي اجراي دستي فراهم مي كند.
اجراي اين playbook اقدامات زير را در هاست Ansible شما انجام خواهد داد:
1) aptitude را نصب ميكند ، كه توسط Ansible به عنوان جايگزيني براي مدير بسته apt ارجحيت داده ميشود.
2)بسته هاي LAMP مورد نياز و پسوندهاي PHP را نصب ميكند.
3) يك Apache VirtualHost جديد براي وب سايت وردپرس ايجاد و فعال مينمايد.
4) ماژول بازنويسي Apache (mod_rewrite) را فعال ميكند.
5) وب سايت پيش فرض Apache را غيرفعال ميكند.
6) رمز ورود را براي كاربر root MySQL تنظيم ميكند.
7) حساب هاي MySQL ناشناس را حذف و پايگاه داده را آزمايش ميكند.
8) براي وب سايت وردپرس يك بانك اطلاعاتي MySQL و كاربر جديد ايجاد ميكند.
9)UFW را تنظيم ميكند تا ترافيك HTTP روي درگاه پيكربندي شده انجام شود (به طور پيش فرض 80).
10) وردپرس را دانلود و باز ميكند.
11) مالكيت و مجوزهاي صحيح دايركتوري را تنظيم ميكند.
12) با استفاده از الگوي ارائه شده ، فايل wp-config.php را تنظيم كنيد.
پس از پايان كار playbook ، بر اساس گزينه هايي كه در متغيرهاي پيكربندي خود تعريف كرده ايد ، يك نصب وردپرس در يك محيط LAMP اجرا مي شود.
نحوه استفاده از اين Playbook
اولين كاري كه ما بايد انجام دهيم اين است كه وردپرس را در playbook LAMP و متعلقات آن از منبع do-community / ansible-playbooks را دريافت كنيم. ما بايد اين منبع را به يك پوشه محلي در داخل گره كنترل Ansible تبديل كنيم.
اگر قبلا با دنبال كردن راهنماي ديگري ، اين منبع را كلون كرده ايد ، به كپيansible-playbooks موجود خود دسترسي پيدا كنيد و يك دستور git pull را اجرا كنيد تا مطمئن شويد كه مطالب به روز شده را داريد:
⦁ $ cd ~/ansible-playbooks

⦁ $ git pull
اگر اين اولين بار است كه از منابع do-community / ansible-playbooks استفاده مي كنيد ، بايد با كلون كردن منبع در پوشه هوم فولدر خود شروع كنيد:
⦁ $ cd ~

⦁ $ git clone https://github.com/do-community/ansible-playbooks.git

⦁ $ cd ansible-playbooks

فايل هاي مورد علاقه ما در داخل پوشه wordpress-lamp_ubuntu1804 قرار گرفته اند كه داراي ساختار زير است:
wordpress-lamp_ubuntu1804
├── files
│ ├── apache.conf.j2
│ └── wp-config.php.j2
├── vars
│ └── default.yml
├── playbook.yml
└── readme.md

در اينجا در مورد هر يك از اين فايل ها آمده است:
files / apache.conf.j2: فايل الگو براي تنظيم Apache VirtualHost.
files / wp-config.php.j2: فايل الگو براي تنظيم فايل پيكربندي WordPress.
vars / default.yml: فايل متغير براي شخصي سازي تنظيمات playbook.
playbook.yml: فايل playbook ، شامل كارهايي كه بايد روي سرور مجازي راه دور اجرا شود.
readme.md: فايل متني حاوي اطلاعات مربوط به اين playbook .
ما براي سفارشي سازي گزينه هاي playbook ، فايل متغيرهاي آن را ويرايش خواهيم كرد. به دايركتوري wordpress-lamp_ubuntu1804 دسترسي پيدا كنيد و فايل vars / default.yml را با استفاده از ويرايشگر خط فرمان مورد نظر خود باز كنيد:
⦁ $ cd wordpress-lamp_ubuntu1804

⦁ $ nano vars/default.yml
اين فايل شامل چند متغير است كه بايد به آن توجه كنيد:
vars/default.yml

#System Settings
php_modules: [ ‘php-curl’, ‘php-gd’, ‘php-mbstring’, ‘php-xml’, ‘php-xmlrpc’, ‘php-soap’, ‘php-intl’, ‘php-zip’ ]

#MySQL Settings
mysql_root_password: “mysql_root_password”
mysql_db: “wordpress”
mysql_user: “sammy”
mysql_password: “password”

#HTTP Settings
http_host: “your_domain”
http_conf: “your_domain.conf”
http_port: “80”

ليست زير شامل توضيح مختصري در مورد هر يك از اين متغيرها و نحوه تغيير آنها مي باشد:
php_modules: آرايه اي حاوي افزونه هاي PHP كه بايد براي پشتيباني از راه اندازي وردپرس شما نصب شوند. شما نيازي به تغيير اين متغير نداريد ، اما در صورت نياز براي ستاپ خاص شما، بايد افزودنه هاي جديد به ليست اضافه كنيد.
mysql_root_password: كلمه عبور مورد نظر براي حساب MySQL ريشه
mysql_db: نام پايگاه داده MySQL كه بايد براي وردپرس ايجاد شود.
mysql_user: نام كاربر MySQL كه بايد براي وردپرس ايجاد شود.
mysql_password: رمز عبور براي كاربر جديد MySQL.
http_host: نام دامنه شما.
http_conf: نام فايل پيكربندي كه در Apache ايجاد مي شود.
http_port: درگاه HTTP براي اين هاست مجازي ، كه به طور پيش فرض 80 است.
پس از اتمام به روزرساني متغيرهاي داخل vars / default.yml ، اين فايل را ذخيره كنيد و ببنديد. اگر از nano استفاده كرده ايد ، اين كار را با فشار دادن CTRL + X ، Y انجام دهيد. سپس enter را بزنيد.
اكنون آماده اجراي اين playbook در يك يا چند سرور مجازي هستيد. بيشتر playbook ها به گونه پيش فرض تنظيم شده اند كه در هر سرور مجازي موجود شما اجرا مي شود. ما مي توانيم از فلگ -l استفاده كنيم تا مطمئن شويم كه فقط يك زير مجموعه از سرور مجازي ها يا يك سرور مجازي منفرد تحت تأثير Playbook قرار گرفته است. ما همچنين مي توانيم از فلگ -u استفاده كنيم تا مشخص كنيم از كدام كاربر روي سرور مجازي از راه دور استفاده مي كنيم تا دستورات playbook را روي ميزبان از راه دور متصل كنيم.
براي اجراي playbook فقط در server1 ، با اتصال به عنوان sammy ، مي توانيد از دستور زير استفاده كنيد:
⦁ $ ansible-playbook playbook.yml -l server1 -u sammy

خروجي مشابه اين دريافت خواهيد كرد:
Output
PLAY [all] *****************************************************************************************************************************

TASK [Gathering Facts] *****************************************************************************************************************
ok: [server1]

TASK [Install prerequisites] ***********************************************************************************************************
ok: [server1]

TASK [Download and unpack latest WordPress] ********************************************************************************************
changed: [server1]

TASK [Set ownership] *******************************************************************************************************************
changed: [server1]

TASK [Set permissions for directories] *************************************************************************************************
changed: [server1]

TASK [Set permissions for files] *******************************************************************************************************
changed: [server1]

TASK [Set up wp-config] ****************************************************************************************************************
changed: [server1]

RUNNING HANDLER [Reload Apache] ********************************************************************************************************
changed: [server1]

RUNNING HANDLER [Restart Apache] *******************************************************************************************************
changed: [server1]

PLAY RECAP *****************************************************************************************************************************
server1 : ok=22 changed=18 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

توجه: براي كسب اطلاعات بيشتر در مورد نحوه اجراي Ansible playbooks ، راهنماي Ansible Cheat Sheet Guide را بررسي كنيد.
پس از پايان راه اندازي Playbook ، مي توانيد به مرورگر وب خود برويد تا نصب وردپرس را از همانجا به پايان برسانيد.
به نام دامنه يا آدرس IP عمومي سرور مجازي خود برويد:
http: // server_host_or_IP
صفحه اي مانند اين را مشاهده خواهيد كرد:

پس از انتخاب زباني كه مي خواهيد براي نصب وردپرس خود استفاده كنيد ، مرحله نهايي براي تنظيم كاربر و رمزعبور وردپرس به شما ارائه مي شود تا بتوانيد وارد كنترل پنل شويد:

با كليك بر روي صفحه ، شما به صفحه اي منتقل مي شويد كه از شما خواسته مي شود وارد شويد:

پس از ورود به سيستم ، شما به داشبورد مديريت وردپرس منتقل مي شويد:

برخي از مراحل بعدي رايج براي سفارشي سازي نصب وردپرس شامل انتخاب تنظيمات permalinks  براي پست هاي شما (مي توانيد در Settings > Permalinks بيابيد) و انتخاب تم جديد (در Appearance > Themes) ميباشد.
محتواي Playbook
مي توانيد تنظيمات سرور LAMP وردپرس را كه در اين آموزش مشاهده شده است ، در پوشه wordpress-lamp_ubuntu1804 در داخل منبع DigitalOcean Community Playbooks مشاهده كنيد. براي كپي يا دانلود مستقيم محتواي اسكريپت ، روي دكمه Raw به سمت بالاي هر اسكريپت كليك كنيد.
محتويات كامل Playbook و همچنين فايل هاي مرتبط با آن نيز براي راحتي شما در اينجا گنجانده شده است.
vars / default.yml
فايل متغير default.yml حاوي مقاديري است كه در وظايف playbook از جمله تنظيمات بانك اطلاعاتي و نام دامنه براي پيكربندي در Apache استفاده خواهد شد.
vars/default.yml
#System Settings
php_modules: [ ‘php-curl’, ‘php-gd’, ‘php-mbstring’, ‘php-xml’, ‘php-xmlrpc’, ‘php-soap’, ‘php-intl’, ‘php-zip’ ]

#MySQL Settings
mysql_root_password: “mysql_root_password”
mysql_db: “wordpress”
mysql_user: “sammy”
mysql_password: “password”

#HTTP Settings
http_host: “your_domain”
http_conf: “your_domain.conf”
http_port: “80”

files/apache.conf.j2
فايل apache.conf.j2 يك فايل الگوي Jinja 2 است كه يك آپشن جديد Apache VirtualHost را پيكربندي مي كند. متغيرهاي مورد استفاده در اين الگو در فايل متغير vars / default.yml تعريف شده اند.
files/apache.conf.j2

ServerAdmin webmaster@localhost
ServerName {{ http_host }}
ServerAlias www.{{ http_host }}
DocumentRoot /var/www/{{ http_host }}
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined


Options -Indexes


DirectoryIndex index.php index.html index.cgi index.pl index.xhtml index.htm

files/wp-config.php.j2
فايل wp-config.php.j2 يكي ديگر از الگوهاي Jinja است كه براي تنظيم فايل اصلي پيكربنديWordPress استفاده مي شود. متغيرهاي مورد استفاده در اين الگو در فايل متغير vars / default.yml تعريف شده اند. كليدهاي احراز هويت منحصر به فرد با استفاده از يك عملكرد تركيبي ايجاد مي شوند.
files/info.php.j2
/**
* The base configuration for WordPress
*
* The wp-config.php creation script uses this file during the
* installation. You don’t have to use the web site, you can
* copy this file to “wp-config.php” and fill in the values.
*
* This file contains the following configurations:
*
* * MySQL settings
* * Secret keys
* * Database table prefix
* * ABSPATH
*
* @link https://codex.wordpress.org/Editing_wp-config.php
*
* @package WordPress
*/

// ** MySQL settings – You can get this info from your web host ** //
/** The name of the database for WordPress */
define( ‘DB_NAME’, ‘{{ mysql_db }}’ );

/** MySQL database username */
define( ‘DB_USER’, ‘{{ mysql_user }}’ );

/** MySQL database password */
define( ‘DB_PASSWORD’, ‘{{ mysql_password }}’ );

/** MySQL hostname */
define( ‘DB_HOST’, ‘localhost’ );

/** Database Charset to use in creating database tables. */
define( ‘DB_CHARSET’, ‘utf8’ );

/** The Database Collate type. Don’t change this if in doubt. */
define( ‘DB_COLLATE’, ” );

/** Filesystem access **/
define(‘FS_METHOD’, ‘direct’);

/**#@+
* Authentication Unique Keys and Salts.
*
* Change these to different unique phrases!
* You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
* You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
*
* @since 2.6.0
*/
define( ‘AUTH_KEY’, ‘{{ ansible_date_time.iso8601_micro | hash(‘sha256′) }}’ );
define( ‘SECURE_AUTH_KEY’, ‘{{ ansible_date_time.iso8601_micro | hash(‘sha256′) }}’ );
define( ‘LOGGED_IN_KEY’, ‘{{ ansible_date_time.iso8601_micro | hash(‘sha256′) }}’ );
define( ‘NONCE_KEY’, ‘{{ ansible_date_time.iso8601_micro | hash(‘sha256′) }}’ );
define( ‘AUTH_SALT’, ‘{{ ansible_date_time.iso8601_micro | hash(‘sha256′) }}’ );
define( ‘SECURE_AUTH_SALT’, ‘{{ ansible_date_time.iso8601_micro | hash(‘sha256′) }}’ );
define( ‘LOGGED_IN_SALT’, ‘{{ ansible_date_time.iso8601_micro | hash(‘sha256′) }}’ );
define( ‘NONCE_SALT’, ‘{{ ansible_date_time.iso8601_micro | hash(‘sha256′) }}’ );

/**#@-*/

/**
* WordPress Database Table prefix.
*
* You can have multiple installations in one database if you give each
* a unique prefix. Only numbers, letters, and underscores please!
*/
$table_prefix = ‘wp_’;

/**
* For developers: WordPress debugging mode.
*
* Change this to true to enable the display of notices during development.
* It is strongly recommended that plugin and theme developers use WP_DEBUG
* in their development environments.
*
* For information on other constants that can be used for debugging,
* visit the Codex.
*
* @link https://codex.wordpress.org/Debugging_in_WordPress
*/
define( ‘WP_DEBUG’, false );

/* That’s all, stop editing! Happy publishing. */

/** Absolute path to the WordPress directory. */
if ( ! defined( ‘ABSPATH’ ) ) {
define( ‘ABSPATH’, dirname( __FILE__ ) . ‘/’ );
}

/** Sets up WordPress vars and included files. */
require_once( ABSPATH . ‘wp-settings.php’ );

playbook.yml
فايل playbook.yml جايي است كه كليه وظايف اين مجموعه تعريف شده است. اين كار با تعريف گروه سرور مجازي هايي كه بايد هدف اين مجموعه باشند (all) شروع مي شود ، و پس از آن براي تعريف اينكه وظايف بايد بصورت پيش فرض با افزايش امتياز (sudo) انجام شود يا خير، از become: true استفاده مي كند. سپس ، فايل متغير vars / default.yml را براي بارگذاري گزينه هاي پيكربندي شامل مي شود.
playbook.yml

– hosts: all
become: true
vars_files:
– vars/default.yml

tasks:
– name: Install prerequisites
apt: name=aptitude update_cache=yes state=latest force_apt_get=yes
tags: [ system ]

– name: Install LAMP Packages
apt: name={{ item }} update_cache=yes state=latest
loop: [ ‘apache2’, ‘mysql-server’, ‘python3-pymysql’, ‘php’, ‘php-mysql’, ‘libapache2-mod-php’ ]
tags: [ system ]

– name: Install PHP Extensions
apt: name={{ item }} update_cache=yes state=latest
loop: “{{ php_modules }}”
tags: [ system ]

# Apache Configuration
– name: Create document root
file:
path: “/var/www/{{ http_host }}”
state: directory
owner: “www-data”
group: “www-data”
mode: ‘0755’
tags: [ apache ]

– name: Set up Apache VirtualHost
template:
src: “files/apache.conf.j2”
dest: “/etc/apache2/sites-available/{{ http_conf }}”
notify: Reload Apache
tags: [ apache ]

– name: Enable rewrite module
shell: /usr/sbin/a2enmod rewrite
notify: Reload Apache
tags: [ apache ]

– name: Enable new site
shell: /usr/sbin/a2ensite {{ http_conf }}
notify: Reload Apache
tags: [ apache ]

– name: Disable default Apache site
shell: /usr/sbin/a2dissite 000-default.conf
notify: Restart Apache
tags: [ apache ]

# MySQL Configuration
– name: Set the root password
mysql_user:
name: root
password: “{{ mysql_root_password }}”
login_unix_socket: /var/run/mysqld/mysqld.sock
tags: [ mysql, mysql-root ]

– name: Remove all anonymous user accounts
mysql_user:
name: ”
host_all: yes
state: absent
login_user: root
login_password: “{{ mysql_root_password }}”
tags: [ mysql ]

– name: Remove the MySQL test database
mysql_db:
name: test
state: absent
login_user: root
login_password: “{{ mysql_root_password }}”
tags: [ mysql ]

– name: Creates database for WordPress
mysql_db:
name: “{{ mysql_db }}”
state: present
login_user: root
login_password: “{{ mysql_root_password }}”
tags: [ mysql ]

– name: Create MySQL user for WordPress
mysql_user:
name: “{{ mysql_user }}”
password: “{{ mysql_password }}”
priv: “{{ mysql_db }}.*:ALL”
state: present
login_user: root
login_password: “{{ mysql_root_password }}”
tags: [ mysql ]

# UFW Configuration
– name: “UFW – Allow HTTP on port {{ http_port }}”
ufw:
rule: allow
port: “{{ http_port }}”
proto: tcp
tags: [ system ]

# WordPress Configuration
– name: Download and unpack latest WordPress
unarchive:
src: https://wordpress.org/latest.tar.gz
dest: “/var/www/{{ http_host }}”
remote_src: yes
creates: “/var/www/{{ http_host }}/wordpress”
tags: [ wordpress ]

– name: Set ownership
file:
path: “/var/www/{{ http_host }}”
state: directory
recurse: yes
owner: www-data
group: www-data
tags: [ wordpress ]

– name: Set permissions for directories
shell: “/usr/bin/find /var/www/{{ http_host }}/wordpress/ -type d -exec chmod 750 {} ;”
tags: [ wordpress ]

– name: Set permissions for files
shell: “/usr/bin/find /var/www/{{ http_host }}/wordpress/ -type f -exec chmod 640 {} ;”
tags: [ wordpress ]

– name: Set up wp-config
template:
src: “files/wp-config.php.j2”
dest: “/var/www/{{ http_host }}/wordpress/wp-config.php”
tags: [ wordpress ]

handlers:
– name: Reload Apache
service:
name: apache2
state: reloaded

– name: Restart Apache
service:
name: apache2
state: restarted

با خيال راحت اين فايل ها را به بهترين وجه متناسب با نيازهاي فردي خود در گردش كارتان تغيير دهيد.
نتيجه
در اين راهنما ، ما از Ansible براي خودكارسازي روند نصب و راه اندازي وب سايت وردپرس با LAMP روي سرور مجازي اوبونتو 18.04 استفاده كرده ايم.
اگر مي خواهيد كارهاي ديگري در اين playbook  را براي سفارشي سازي تنظيمات سرور مجازي خود انجام دهيد ، لطفاً به راهنماي مقدماتي Ansible ( پيكربندي مديريت 101: نوشتن Ansible Playbooks) مراجعه كنيد.


برچسب: ،
بازدید:

ادامه مطلب

نوشته شده: ۸ بهمن ۱۳۹۸ساعت: ۰۱:۲۸:۴۲ توسط:server موضوع:

چگونه مي توان پلتفرم كد سرور Cloud IDE را در اوبونتو 18.04 تنظيم كرد (شروع سريع)

مقدمه
code-server يك كد مايكروسافت ويژوال استوديو است كه روي يك سرور مجازي از راه دور اجرا مي شود و مستقيماً از مرورگر شما قابل دسترسي است. اين بدان معني است كه مي توانيد از دستگاه هاي مختلف با سيستم عامل هاي مختلف استفاده كنيد و هميشه يك محيط توسعه مداوم داشته باشيد.
در اين آموزش ، پلت فرم cloud IDE كد سرور مجازي را بر روي دستگاه Ubuntu 18.04 خود تنظيم كرده و آن را در دامنه خود قرار مي دهيد ، كه با Let’s Encrypt ايمن شده است. براي نسخه دقيق تر اين آموزش ، به نحوه راه اندازي رمز سرور مجازي Cloud IDE در اوبونتو 18.04 مراجعه كنيد.
پيش نيازها
⦁ سرور مجازي كه اوبونتو 18.04 را اجرا ميكند با حداقل 2 گيگابايت حافظه رم ، دسترسي به ريشه و يك حساب سودو و غير ريشه. مي توانيد اين كار را با دنبال كردن راهنماي اوليه تنظيم سرور مجازي Ubuntu 18.04 انجام دهيد.
⦁ Nginx كه روي سرور مجازي شما نصب شده است. براي راهنمايي در مورد نحوه انجام اين كار ، مراحل 1 تا 4 نحوه نصب Nginx را در اوبونتو 18.04 مطالعه كنيد.
⦁ يك نام دامنه به طور كامل ثبت شده براي هاست كد سرور مجازي ، كه به سرور مجازي شما اشاره ميكند. در اين آموزش از code-server.your-domain استفاده مي شود. مي توانيد نام دامنه را در Namecheap خريداري كنيد ، يكي از آنها را به صورت رايگان در Freenom دريافت كنيد ، يا از ثبت دامنه مورد نظر خود استفاده كنيد.
⦁ هر دو سابقه DNS زير براي سرور مجازي شما تنظيم شده اند. براي جزئيات بيشتر در مورد چگونگي اضافه كردن آنها مي توانيد اين مقدمه را در DigitalOcean DNS دنبال كنيد.
⦁ يك پرونده با your-domain كه آدرس IP عمومي سرور مجازي شما را نشان مي دهد.
⦁ يك پرونده با دامنه www. your-domain كه آدرس IP عمومي سرور مجازي شما را نشان مي دهد.
مرحله 1 – نصب كد سرور مجازي
براي ذخيره كليه داده ها براي كد سرور مجازي ، دايركتوري زير را ايجاد كنيد:
⦁ $ mkdir ~/code-server
به سمت آن جهت دهي كنيد:
⦁ $ cd ~/code-server
به صفحه نسخه هاي كد سرور مجازي Github مراجعه كرده و آخرين لينوكس را انتخاب كنيد. آن را با استفاده از آدرس زير دانلود كنيد:

⦁ $ wget https://github.com/cdr/code-server/releases/download/2.1692-vsc1.39.2/code-server2.1692-vsc1.39.2-linux-x86_64.tar.gz

آرشيو را باز كنيد:
⦁ $ tar -xzvf code-server2.1692-vsc1.39.2-linux-x86_64.tar.gz

به ديركتوري حاوي كد سرور مجازي قابل اجرا برويد:
⦁ $ cd code-server2.1692-vsc1.39.2-linux-x86_64

براي دسترسي به كد سرور مجازي قابل اجرا در سيستم خود ، آن را با دستور زير كپي كنيد:
⦁ $ cd code-server2.1692-vsc1.39.2-linux-x86_64

پوشه اي براي كد سرور مجازي ايجاد كنيد تا داده هاي كاربر ذخيره شود:
⦁ $ sudo mkdir /var/lib/code-server

يك سرويس سيستمي ، code-server.service ، در ديركتوري / lib / systemd / system ايجاد كنيد:
⦁ $ sudo nano /lib/systemd/system/code-server.service

خطوط زير را اضافه كنيد:

/lib/systemd/system/code-server.service
[واحد]
توضيحات = سرور مجازي كد
پس از = nginx.service

[سرويس]
نوع = ساده
محيط = PASSWORD = كلمه كليدي شما
ExecStart = / usr / local / bin / code-server – host 127.0.0.1 –user-data-dir / var / lib / code-server – رمز ورود
راه اندازي مجدد = هميشه

[نصب]
WantedBy = multi-user.targe /lib/systemd/system/code-server.service
[Unit]
Description=code-server
After=nginx.service

[Service]
Type=simple
Environment=PASSWORD=your_password
ExecStart=/usr/local/bin/code-server –host 127.0.0.1 –user-data-dir /var/lib/code-server –auth password
Restart=always

[Install]
WantedBy=multi-user.target
–host 127.0.0.1 آن را به localhost متصل مي كند.
–user-data-dir /var/lib/code-server دايركتوري داده هاي كاربر آن را تنظيم مي كند.
–auth password مشخص مي كند كه بايد بازديد كنندگاني معتبر با رمز عبور وجود داشته باشند.
به ياد داشته باشيد كه your_password را با رمز عبور دلخواه خود جايگزين كنيد.
فايل را ذخيره كنيد و ببنديد.
سرويس كد سرور مجازي را شروع كنيد:
⦁ $ sudo systemctl start code-server

بررسي كنيد كه به درستي شروع شده است:

⦁ $ sudo systemctl status code-server

خروجي مشابه با زير مشاهده ميكنيد:
Output
● code-server.service – code-server
Loaded: loaded (/lib/systemd/system/code-server.service; disabled; vendor preset: enabled)
Active: active (running) since Mon 2019-12-09 20:07:28 UTC; 4s ago
Main PID: 5216 (code-server)
Tasks: 23 (limit: 2362)
CGroup: /system.slice/code-server.service
├─5216 /usr/local/bin/code-server –host 127.0.0.1 –user-data-dir /var/lib/code-server –auth password
└─5240 /usr/local/bin/code-server –host 127.0.0.1 –user-data-dir /var/lib/code-server –auth password

بعد از راه اندازي مجدد سرور مجازي ، سرويس كد سرور مجازي را فعال كنيد:
⦁ $ sudo systemctl enable code-server

مرحله 2 – به نمايش گذاشتن كد سرور مجازي
اكنون Nginx را به عنوان يك پروكسي معكوس براي كد سرور مجازي پيكربندي خواهيد كرد.
براي ذخيره پيكربندي جهت نمايش دادن كد سرور مجازي در دامنه خود ، code-server.conf را ايجاد كنيد:
sudo nano /etc/nginx/sites-available/code-server.conf
خطوط زير را براي تنظيم بلوك سرور مجازي خود با دستورالعمل هاي لازم اضافه كنيد:
/etc/nginx/sites-available/code-server.conf
server {
listen 80;
listen [::]:80;

server_name code-server.your_domain;

location / {
proxy_pass http://localhost:8080/;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection upgrade;
proxy_set_header Accept-Encoding gzip;
}
}
code-server.your_domain را با دامنه مورد نظر خود جايگزين كنيد ، سپس فايل را ذخيره كنيد و ببنديد.
براي فعال كردن پيكربندي اين سايت ، يك سيملينك از آن ايجاد كنيد:
⦁ $ sudo ln -s /etc/nginx/sites-available/code-server.conf /etc/nginx/sites-enabled/code-server.conf

اعتبار پيكربندي را تست كنيد:
⦁ $ sudo nginx -t

خروجي زير را مشاهده خواهيد كرد:
Output
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

براي اجراي پيكربندي ، Nginx را مجدداً راه اندازي كنيد:
⦁ $ sudo systemctl restart nginx

مرحله 3 – دامنه خود را ايمن كنيد
اكنون دامنه خود را با استفاده از گواهي Let’s Encrypt TLS ايمن مي كنيد.
منبع بسته Certbot را به سرور مجازي خود اضافه كنيد:
⦁ $ sudo add-apt-repository ppa:certbot/certbot

Certbot و افزونه Nginx آن را نصب كنيد:
⦁ $ sudo apt install python-certbot-nginx

ufw را براي پذيرش ترافيك رمزگذاري شده پيكربندي كنيد:
⦁ $ sudo ufw allow https

خروجي به شكل زير خواهد بود:
Output
Rule added
Rule added (v6)

براي پيكربندي براي اجرا مجدد آن را بارگذاري كنيد:
⦁ $ sudo ufw reload

خروجي زير نشان داده مي شود:
Output
Firewall reloaded

به دامنه كد سرور مجازي خود برويد.

رمز عبور سرور مجازي كد خود را وارد كنيد. مرز نمايش داده شده در دامنه خود را مشاهده خواهيد كرد.

براي تأمين امنيت آن ، يك مجوز Let’s Encrypt TLS با استفاده از Certbot نصب كنيد.
براي دامنه خود با دستور زير درخواست يك مجوز بدهيد:
⦁ $ sudo certbot –nginx -d code-server.your_domain

براي اطلاع رساني هاي فوري يك آدرس ايميل ارائه دهيد ، شرايط خدمات EFF را بپذيريد ، و تصميم بگيريد كه آيا تمام ترافيك HTTP را به HTTPS هدايت كنيد يا خير.
خروجي مشابه زير خواهد بود:
Output
IMPORTANT NOTES:
– Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/code-server.your_domain/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/code-server.your_domain/privkey.pem
Your cert will expire on … To obtain a new or tweaked
version of this certificate in the future, simply run certbot again
with the “certonly” option. To non-interactively renew *all* of
your certificates, run “certbot renew”

Certbot با موفقيت گواهينامه هاي TLS را ايجاد ميكند و آنها را در پيكربندي Nginx براي دامنه شما اعمال مي نمايد.
نتيجه
اكنون شما داراي كد سرور مجازي ، و يك cloud IDE همه كاره هستيد كه بر روي سرور مجازي Ubuntu 18.04 نصب شده است ، در دامنه شما قرار گرفته و با استفاده از گواهي نامه هاي Let’s Encrypt ايمن شده است. براي اطلاعات بيشتر در مورد ويژگي ها و دستورالعمل هاي دقيق در مورد ساير مؤلفه هاي كد سرور مجازي ، به مطالب ويژوال استوديو كد مراجعه كنيد.


برچسب: ،
بازدید:

ادامه مطلب

نوشته شده: ۸ بهمن ۱۳۹۸ساعت: ۰۱:۲۸:۱۷ توسط:server موضوع:

چگونه مي توان از رول هاي ansible براي انتزاع محيط زيرساختي خود استفاده كرد

مقدمه
Ansible يك ابزار مديريت پيكربندي است كه براي خودكار سازي سرور مجازي هاي كنترل كننده براي مديران و تيم هاي عملياتي طراحي شده است. با استفاده از Ansible مي توانيد از يك سرور مجازي مركزي منفرد استفاده كنيد تا بسياري از سيستمهاي مختلف از راه دور را با استفاده از SSH و Python به عنوان تنها ابزار مورد نياز كنترل و پيكربندي كنيد.
Ansible وظايف خود را بر روي سرور مجازي هايي انجام مي دهد كه بر اساس تعريف وظيفه آنها را مديريت مي كند. اين كارها از ماژول هاي داخلي Ansible با استفاده از قطعه هاي كوچك YAML براي هر كار استفاده مي كند.
هرچه تعداد و تنوع سيستمهايي كه شما با يك گره كنترل Ansible مديريت مي كنيد پيچيده تر مي شود ، معقول است كه وظايف را با هم در playbooks Ansible گروه بندي كنيد. استفاده از اين playbook ها نياز به اجراي بسياري از وظايف فردي روي سيستم هاي از راه دور را برطرف مي كند ، در عوض به شما امكان مي دهد تمام محيط ها را به طور هم زمان با يك فايل واحد پيكربندي كنيد.
با اين حال ، وقتي كه playbooks وظيفه تنظيم بسياري از سيستم هاي مختلف با كارهاي مختلف براي هر سيستم را دارند ، مي توانند پيچيده تر شوند بنابراين Ansible همچنين به شما امكان مي دهد تا وظايفي را در يك ساختار دايركتوري به نام Role سازماندهي كنيد. در اين پيكربندي ، playbooks به جاي وظايف ، رول ها را فراخواني مي كنند ، بنابراين شما هنوز هم مي توانيد وظايف را با هم گروه بندي كرده و سپس در ساير playbooks از رول ها استفاده مجدد كنيد. رول ها همچنين به شما امكان مي دهد قالب ها ، فايل هاي استاتيك و متغيرها را به همراه كارهاي خود در يك قالب ساختاري جمع آوري كنيد.
در اين آموزش چگونگي ايجاد رول ها و چگونگي اضافه كردن قالب ها ، فايل هاي استاتيك و متغيرها به يك رول مورد بررسي قرار خواهد گرفت. پس از آشنايي با اصول رول هاي ساختاي ، از Ansible Galaxy استفاده خواهيم كرد تا رول هاي مرتبط با جامعه را در playbooks وارد كنيم. با پايان اين آموزش قادر خواهيد بود براي سرور مجازي هاي خود رول هاي خاص محيطي خود را ايجاد كرده و از آنها در playbooks خود استفاده كنيد تا يك يا بسياري از سيستم ها را مديريت كنيد.
پيش نيازها
براي دنبال كردن اين آموزش ، بايد Ansible را نصب و پيكربندي كنيد تا بتوانيد playbooks را ايجاد و اجرا كنيد. شما همچنين نياز به درك نحوه نوشتن playbooks Ansible حساس داريد.
رول Ansible چيست؟
در آموزش هاي پيش نياز ، شما ياد گرفتيد كه چگونه ابزار اصلي Ansible را با استفاده از دستور ansible در يك ترمينال اجرا كنيد. همچنين آموخته ايد كه چگونه وظايف را در playbooks جمع آوري كرده و آنها را با استفاده از دستور playbooks ansible اجرا كنيد. مرحله بعدي رفتن از اجراي دستورات منفرد ، به سمت وظايف ، و playbooks ، سازماندهي مجدد همه چيز با استفاده از يك رول Ansible است.

رول ها سطحي از انتزاع در صدر كارها و playbook هستند كه به شما امكان مي دهد پيكربندي Ansible خود را در قالب مدولار و قابل استفاده مجدد سازماندهي كنيد. هرچه عملكرد و انعطاف پذيري بيشتري را به playbooks خود اضافه مي كنيد ، آنها گسترده ميشوند و نگهداري شان مي تواند دشوار شود. رول ها به شما امكان مي دهد يك playbook پيچيده را به بخش هاي جداگانه و كوچكتر تقسيم كنيد كه با يك نقطه ورودي مركزي هماهنگ شوند. به عنوان مثال ، در اين آموزش كل playbook.yml كه با آنها كار خواهيم كرد به شرح زير است:
Example Playbook
1—

2- hosts: all

3 become: true
4 roles:
5 – apache

6 vars:

7 doc_root: /var/www/example

مجموعه تمام كارهايي كه براي پيكربندي يك وب سرور مجازي Apache انجام مي شود ، در رول apache كه ايجاد خواهيم كرد ، درج خواهد شد. اين رول به جاي ليست كردن تكاليف به صورت جداگانه مانند آنچه در نسخه پيكربندي مديريت 101 انجام داديم ، به شرح زير تمام كارهايي را كه بايد براي نصب Apache انجام شود ، تعريف مي كند.
ساماندهي ستاپ Ansible  شما به صورت رول ها به شما امكان مي دهد از مراحل پيكربندي مشترك بين انواع مختلف سرور مجازيها مجدد استفاده كنيد. حتي اگر اين كار با وجود چندين فايل وظيفه در يك playbook نيز امكان پذير باشد ، رول ها به ساختار دايركتوري شناخته شده و كنوانسيون نام فايل متكي هستند تا به صورت خودكار فايل هايي كه در اين بازي استفاده مي شوند را بارگيري كنند.
به طور كلي ، ايده هاي پشت رول ها اين است كه به شما امكان مي دهد با استفاده از يك ساختار پايدار ، وظايف خود را با يكديگر به اشتراك بگذاريد و از آنها استفاده مجدد كنيد ، در حالي كه نگهداري آنها بدون انجام كارهاي تكراري براي همه زيرساخت هاي شما آسان مي شود.
ايجاد رول
براي ايجاد رول Ansible  به يك ساختار دايركتوري اختصاصي نياز داريد. رول ها هميشه به اين طرح دايركتوري نياز دارند تا Ansible بتواند آنها را پيدا كرده و از آنها استفاده كند.

ما در اينجا فرض مي كنيم كه از دايركتوري هوم كاربر به عنوان دايركتوري كاربري Ansible استفاده كرده ايد. اگر پيكربندي Ansible خود را در يك مكان ديگر نگه داشته باشيد ، بايد (cd) را در آن ديركتوري تغيير دهيد.
براي شروع ، بياييد دايركتوري به نام roles ايجاد كنيم. وقتي مي خواهيم در ادامه اين آموزش رول جديد خود را در يك playbook  استفاده كنيم، Ansible به اينجا نگاه مي كند.
$ cd ~

$ mkdir roles

$ cd roles
در اين دايركتوري رول هايي را تعريف خواهيم كرد كه قابل استفاده مجدد در چندين playbook  و سرور مجازي هاي مختلف هستند. هر رولي كه ايجاد خواهيم كرد نياز به ديركتوري خاص خود دارد. ما مي خواهيم نمونه playbook  Apache را از آموزش  Configuration Management 101: Writing Ansible Playbooks  بگيريم و آن را به يك رول قابل استفاده مجدد Ansible تبديل كنيم.
براي ارجاع، اين playbook  از آن آموزش است:
playbook.yml
1—
2- hosts: all
3 become: true
4 vars:
5 doc_root: /var/www/example
6 tasks:
7 – name: Update apt
8 apt: update_cache=yes
9
10 – name: Install Apache

11 apt: name=apache2 state=latest
12
13 – name: Create custom document root
14 file: path={{ doc_root }} state=directory owner=www-data group=www-data
15
16 – name: Set up HTML file

17 copy: src=index.html dest={{ doc_root }}/index.html owner=www-data group=www-data mode=0644
18
19 – name: Set up Apache virtual host file
20 template: src=vhost.tpl dest=/etc/apache2/sites-available/000-default.conf
21 notify: restart apache
22
23 handlers:
24 – name: restart apache
25 service: name=apache2 state=restarted
در ابتدا ، يك دايركتوري Apache براي رول خود ايجاد مي كنيم و آن را با ديركتوري هاي مورد نياز جمع كنيم:
$ mkdir apache

$ cd apache
در مرحله بعدي مجموعه زير دايركتوري هاي مورد نياز را ايجاد خواهيم كرد كه به Ansible اطلاع مي دهد كه بايد از محتويات به عنوان يك رول استفاده كند. با استفاده از دستور mkdir اين دايركتوري ها را ايجاد كنيد:
$ mkdir defaults files handlers meta templates tasks vars
اين ديركتوري ها براي اجراي رول ما شامل كليه كد ها مي باشند. بسياري از رول ها بسته به پيچيدگي كارهايي كه انجام مي دهند فقط از يك يا چند مورد از اين دايركتوري ها استفاده خواهند كرد. هنگام نوشتن رول هاي خود ، ممكن است نيازي به ايجاد همه اين دايركتوري ها نباشد.
در اينجا توضيحي در مورد آنچه هر دايركتوري نشان مي دهد آورده شده است:
defaults: اين دايركتوري به شما امكان مي دهد متغيرهاي پيش فرض را براي رول هاي شامل يا وابسته تنظيم كنيد. هر پيش فرض تنظيم شده در اينجا مي تواند در playbooks  يا فايل هاي موجودي تنظيم شود.
files: اين دايركتوري حاوي فايل هاي استاتيك و فايلهاي اسكريپتي است كه ممكن است در يك سرور مجازي از راه دور كپي شده يا اجرا شوند.
handlers : همه هندلر هايي كه قبلاً در playbooks  شما بوده اند اكنون مي توانند در اين دايركتوري قرار بگيرند.
Meta : اين دايركتوري براي ابرداده رول ها ، كه معمولاً براي مديريت وابستگي استفاده مي شود ، محفوظ است. به عنوان مثال ، مي توانيد ليستي از رول ها را تعريف كنيد كه بايد قبل از استناد به رول فعلي اعمال شوند.
templates: اين دايركتوري براي قالب هايي اختصاص داده شده است كه توليد فايل در هاست از راه دور را انجام ميدهند. قالب ها معمولاً از متغيرهايي استفاده مي كنند كه در فايل هاي واقع در دايركتوري vars و اطلاعات جمع آوري شده هاست در زمان اجرا، تعريف شده اند.
tasks: اين دايركتوري شامل يك يا چند فايل با كارهايي است كه بطور معمول در بخش وظايف يك playbook معمولي Ansible تعريف مي شود. اين كارها مي توانند به طور مستقيم فايل ها و الگوهاي موجود در دايركتوري هاي مربوطه خود را در داخل رول ، بدون نياز به ارائه مسير كاملي براي فايل ، ارجاع دهند.
Vars : متغيرهاي يك رول را مي توان در فايل هاي داخل اين دايركتوري مشخص كرد و سپس به مكان ديگري در يك رول ارجاع داد.
اگر فايلي به نام main.yml در يك دايركتوري وجود داشته باشد ، محتواي آن به طور خودكار به playbook اي كه رول را فراميخواند اضافه مي شود. با اين حال ، اين امر در مورد دايركتوري هاي files  و templates  صدق نمي كند ، زيرا محتواي آنها به صراحت ارجاع داده شود.
تبديل يك Playbook به يك رول
اكنون كه با آنچه در هر دايركتوري در رول Ansible استفاده مي شود آشنا هستيد ، مي توانيم playbook Apache را به رولي تبديل كنيم تا امور بهتر سازماندهي شود.
ما بايد ساختارهاي role / / apache2 / d subdirectories from را از قسمت آخر تنظيم كنيم. حال بايد برخي از فايلهاي YAML را براي تعريف رول خود ايجاد كنيم.
ايجاد فايل main.yml كارها
ما با زيرمجموعه وظايف شروع خواهيم كرد. اكنون به آن دايركتوري منتقل ميشويم:
$ cd ~/roles/apache/tasks
ما بايد يك فايل main.yml را در اين دايركتوري ايجاد كنيم. آن را با كل محتواي Playbook Apache جمع مي كنيم و سپس ويرايش مي كنيم تا فقط شامل وظايف باشد.
$ nano main.yml
وقتي شروع مي كنيد ، فايل بايد از اين قرار باشد:

main.yml
1—
2- hosts: all
3 become: true
vars:
5 _root: /var/www/example
6
7 tasks:
– name: Update apt
9 apt: update_cache=yes
10
11- name: Install Apache
12 apt: name=apache2 state=latest
13
14 – name: Create custom document root
15 file: path={{ doc_root }} state=directory owner=www-data group=www-data
16
17 – name: Set up HTML file

18 copy: src=index.html dest={{ doc_root }}/index.html owner=www-data group=www-data mode=0644
19
20 – name: Set up Apache virtual host file
21 template: src=vhost.tpl dest=/etc/apache2/sites-available/000-default.conf
22 notify: restart apache
23
24 handlers:
25 – name: restart apache
26 service: name=apache2 state=restarted
ما فقط مي خواهيم خط اول — و خطوط قسمت tasks را برجسته نگه داريم. ما همچنين مي توانيم فضاهاي فرعي را به سمت چپ وظايف خود حذف كنيم. همچنين براي فعال كردن يك ماژول Apache به نام modsecurance يك بخش جديد اضافه خواهيم كرد كه بعداً در اين آموزش پيكربندي خواهيم كرد. پس از اين تغييرات ، فايل جديد ~ / role / apache / works / main.yml ما به اين شكل ظاهر مي شود:
main.yml
1—

2- name: Update apt

3 apt: update_cache=yes

4

5- name: Install Apache

6 apt: name=apache2 state=latest

7

8- name: Create custom document root

9 file: path={{ doc_root }} state=directory owner=www-data group=www-data

10

11- name: Set up HTML file

12 copy: src=index.html dest={{ doc_root }}/index.html owner=www-data group=www-data mode=0644

13

14- name: Set up Apache virtual host file
15 template: src=vhost.tpl dest=/etc/apache2/sites-available/000-default.conf

16 notify: restart apache
اكنون پيگيري و فهم فايل tasks آسان تر است زيرا فقط شامل مراحل واقعي است كه هنگام استفاده از رول Apache انجام مي شود.
توجه داشته باشيد كه چگونه خطوط copy و template به ترتيب از src = index.html و src = vhost.tpl براي فايل هاي مرجع در رول ما استفاده مي كنند ، بدون اينكه مسير قبلd داشته باشkد. ساختار دايركتوري رول ما اجازه مي دهد فايل ها و قالب ها را مستقيماً با نام آنها ارجاع دهيم ، و Ansible آنها را به طور خودكار براي ما پيدا مي كند.
هنگام پايان ويرايش آن ، فايل را ذخيره كنيد و ببنديد.
ايجاد فايل main.yml هندلرها
اكنون كه توده اي از playbook را در فايل وظايف / main.yml داريم ، بايد بخش هندلر ها را به يك فايل واقع در handlers / main.yml منتقل كنيم.
ابتدا در زير مجموعه هندلرها در رول ما cd را انجام دهيد:
$ cd ~/roles/apache/handlers
دوباره ، فايل را در ويرايشگر متن خود باز كنيد و كل محتويات اصلي playbook.yml را پيست كنيد:
$ nano main.yml
قسمت هايي كه بايد آنها را نگهداريم دوباره مشخص شده است:
playbook.yml
1—

2- hosts: all

3 become: true

4 vars:

5 doc_root: /var/www/example

6 tasks:

7 – name: Update apt

8 apt: update_cache=yes

9

10 – name: Install Apache

11 apt: name=apache2 state=latest

12

13 – name: Create custom document root

14 file: path={{ doc_root }} state=directory owner=www-data group=www-data

15

16 – name: Set up HTML file
17 copy: src=index.html dest={{ doc_root }}/index.html owner=www-data group=www-data mode=0644
18

19 – name: Set up Apache virtual host file

20 template: src=vhost.tpl dest=/etc/apache2/sites-available/000-default.conf

21 notify: restart apache

22
23 handlers:

24 – name: restart apache
25 service: name=apache2 state=restarted

فضاي سفيد را از جلوي هندلرها نيز رفع كنيد. در پايان ، فايل بايد به صورت زير باشد:

– name: restart apache
service: name=apache2 state=restarted

پس از اتمام فايل را ذخيره كنيد و ببنديد.
افزودن فايل ها و قالب ها
اكنون كه وظايف و هندلرهايي داريم ، مرحله بعدي اين است كه اطمينان حاصل كنيم كه يك فايل index.html و يك الگوي vhost.tpl وجود دارد تا Ansible بتواند آنها را پيدا كند و روي سرور مجازي هاي راه دور ما قرار دهد. از آنجا كه ما به اين فايل ها در فايل هاي tasks/main.yml ارجاع داده ايم ، آنها بايد وجود داشته باشند درغير اين صورتAnsible قادر به اجراي صحيح اين رول نيست.
ابتدا فايل index.html را در دايركتوري ~ / role / apache / files ايجاد كنيد:
$ cd ~/roles/apache/files
$ nano index.html
موارد زير را در ويرايشگر پيست كنيد ، سپس آن را ذخيره كنيد و ببنديد:

Configuration Management Hands On

This server was provisioned using Ansible

سپس الگوي vhost.tpl را ويرايش خواهيم كرد. به ديركتوري templates رفته و فايل را با nano ويرايش كنيد:
$ cd ~/roles/apache/templates
$ nano vhost.tpl
اين خطوط را در ويرايشگر پيست كنيد ، سپس آن را ذخيره كرده و ببنديد:

ServerAdmin webmaster@localhost
DocumentRoot {{ doc_root }}


AllowOverride All
Require all granted

دايركتوري متا
اگر رول ما به رول ديگري بستگي داشت ، مي توانستيم فايلي در دايركتوري متا به نام main.yml اضافه كنيم. اين فايل ممكن است مشخص كند كه اين رول به رولي به نام “apt” بستگي دارد. در رول Apache  كه ما ايجاد كرده ايم هيچ وابستگي لازم نداريم. با اين حال ، در صورت نياز فرضي به رول ديگري مانند “apt” ، فايل در ~ / role / apache / meta / main.yml ممكن است به شرح زير باشد:

dependencies:
– apt

اين تضمين مي كند كه رول “apt” قبل از رول Apache  ما اجرا مي شود. ايجاد وابستگي هايي مانند اين براي رول هاي پيچيده تري كه قبل از اجراي رول واقعي نياز به وجود ساير نرم افزارها يا پيكربندي ها دارند، مفيد است.
دايركتوري Vars
ما قبلاً گفتيم كه يك دايركتوري “vars” وجود دارد كه مي تواند براي تعيين متغيرها براي رول ما استفاده شود. در حالي كه پيكربندي پارامترهاي پيش فرض براي يك رول از طريق فايل vars / main.yml ممكن است ، اين معمولاً براي رول هاي كوچكتر توصيه نمي شود.
دليل استفاده نكردن از دايركتوري “vars” اين است كه باعث مي شود جزئيات پيكربندي شما در سلسله مراتب رول ها قرار بگيرد. رول بيشتر وظايف عمومي و وابستگي را به عهده دارد ، در حالي كه متغيرها داده پيكربندي هستند. اتصال اين دو ، استفاده مجدد از رول شما در جاي ديگر را دشوارتر مي كند.
در عوض ، بهتر است جزئيات پيكربندي را خارج از رول مشخص كنيد تا بتوانيد به راحتي رول را بدون نگراني از افشاي اطلاعات حساس به اشتراك بگذاريد. همچنين ، متغيرهاي اعلام شده در يك رول به راحتي توسط متغيرهاي مكانهاي ديگر رد مي شوند. خيلي بهتر است داده هاي متغير را در playbookهايي قرار دهيد كه براي كارهاي خاص استفاده مي شوند.
با اين حال ، ذكر دايركتوري “vars” هنوز هم خالي از لطف نيست، زيرا با رول هاي پيچيده تر مفيد است. به عنوان مثال ، اگر يك رول به پشتيباني از توزيع هاي مختلف لينوكس نياز دارد ، تعيين مقادير پيش فرض براي متغيرها مي تواند براي مديريت نام هاي مختلف بسته ها ، نسخه ها و تنظيمات مفيد باشد.
شمول فايل هاي ديگر
بعضي مواقع وقتي رول ها با وظايف متعدد ايجاد مي كنيد ، درك و فهم وابستگي ها يا منطق شرطي دشوار خواهد شد. در چنين شرايطي مي توانيد وظايف خود را در فايل هاي خود تقسيم كرده و آنها را در tasks/main.yml قرار دهيد.

به عنوان مثال ، اگر ما يك مجموعه كار اضافي براي پيكربندي TLS براي سرور مجازي Apache خود داشتيم ، مي توانستيم آن ها را در فايل خودشان جدا كنيم. ما مي توانيم فايل tasks/tls.yml را فراخواني كنيم و آن را مانند اين در فايل tasks/main.yml قرار دهيم:
. . .
tasks:
– include: roles/apache/tasks/tls.yml

يك Playbook اسكلتي ايجاد كنيد
اكنون كه ساختار رول خود را پيكربندي كرده ايم ، مي توانيم آن را با حداقل playbook  در مقايسه با نسخه يكپارچه در ابتداي اين آموزش استفاده كنيم.
استفاده از رول ها به اين طريق به ما اين امكان را مي دهد تا از playbooks استفاده كنيم تا آنچه را كه سرور مجازي بايد انجام دهد را بدون نياز به تكرار هميشگي وظايف براي انجام اين كار ، اعلان كنيم.
براي ايجاد يك playbook حداقل كه شامل رول Apache ما باشد ، از دايركتوري رول ها (دايركتوري هوم ما در اين مثال). cd out كنيد. اكنون مي توانيم يك فايل playbook ايجاد كنيم:
$ cd ~
$ nano playbook.yml
پس از باز كردن فايل ، موارد زير را پيست كنيد و سپس فايل را ذخيره كرده و ببنديد:

– hosts: all
become: true
roles:
– apache
vars:
– doc_root: /var/www/example

اطلاعات بسيار كمي در اين فايل مورد نياز است. ابتدا سرور مجازي هايي را كه مي خواهيم اين رول را اجرا كنند ، ليست مي كنيم ، بنابراين از – hosts: all استفاده مي كنيم . اگر گروهي از هاست ها به نام webservers را داشتيد مي توانستيد آنها را هدف قرار دهيد. در مرحله بعد ، اعلام مي كنيم كه از چه رول هايي استفاده مي كنيم. در اين حالت فقط يكي وجود دارد ، بنابراين از خط – apache استفاده مي كنيم.
اين كل playbook ما است كه بسيار كوچك و خواندن و فهميدن آن سريع است. مرتب كردن playbook هايي مانند اين به ما امكان مي دهد تا به جاي فعاليت روي كارهاي شخصي ، روي اهداف كلي براي پيكربندي سرور مجازي تمركز كنيم. حتي نكته بهتر آن كه، اگر چندين رول مورد نياز داشته باشيم ، اكنون مي توانيم آنها را در بخش رول ها در playbook خود ليست كنيم و آنها به ترتيبي كه ظاهر مي شوند اجرا شوند.

به عنوان مثال ، اگر ما براي راه اندازي سرور مجازي وردپرس با استفاده از Apache و MySQL رول هايي داشتيم ، احتمالا playbook داشتيم كه مشابه زير ميبود:

– hosts: wordpress_hosts
become: true
roles:
– apache
– php
– mysql
– wordpress
vars:
– doc_root: /var/www/example

اين ساختار playbook به ما امكان مي دهد درباره اين كه مي خواهيم يك سرور مجازي چگونه باشد ، خيلي دقيق پيش برويم. سرانجام ، از آنجا كه playbook ها رول ها را فرا ميخوانند ، دستور اجراي ما دقيقاً مشابه حالتي است كه گويا همه در يك فايل واحد قرار گرفته اند:
$ ansible-playbook playbook.yml

Output
PLAY [all] ******************************************************************************************

TASK [Gathering Facts] ******************************************************
ok: [64.225.15.1]

TASK [apache : Update apt] **************************************************
ok: [64.225.15.1]

TASK [apache : Install Apache] **********************************************
changed: [64.225.15.1]

TASK [apache : Create custom document root] *********************************
changed: [64.225.15.1]

TASK [apache : Set up HTML file] ********************************************
changed: [64.225.15.1]

TASK [apache : Set up Apache virtual host file] *****************************
changed: [64.225.15.1]

RUNNING HANDLER [apache : restart apache] ***********************************
changed: [64.225.15.1]

PLAY RECAP ******************************************************************
64.225.15.1 : ok=7 changed=5 unreachable=0 failed=0

به عنوان مثال مي توانيد فايل playbook.yml به نام apache.yml را فراخواني كنيد ، تا نام فايل رول (هاي) موجود در آن را منعكس كند.
گلكسي Ansible
آموزش در مورد رول هاي Ansible بدون بررسي منابع موجود از طريق Galaxy Ansible كامل نخواهد بود. كهكشان جستجوگر ، منبعي از رول هاي كمكي كاربر است كه مي توانيد براي انجام كارهاي مختلف بدون نياز به نوشتن آنها ، به playbooks اضافه كنيد.
به عنوان مثال ، مي توانيم يك ماژول مفيد Apache به نام mod_security2 را به playbook خود اضافه كنيم تا آپاچي را با برخي تنظيمات امنيتي اضافي پيكربندي كنيم. ما از يك رول ansible Galaxy با عنوان apache_modsecurance استفاده خواهيم كرد. براي استفاده از اين رول ، آن را به صورت محلي دانلود خواهيم كرد و سپس آن را در playbook خود قرار خواهيم داد.
ابتدا با ابزار ansible-galaxy آشنا مي شويم. ما با استفاده از ابزار Galaxy را جستجو خواهيم كرد و سپس يك رول را از ليست انتخاب شده از دستور جستجو انتخاب مي كنيم:
$ ansible-galaxy search “PHP for RedHat/CentOS/Fedora/Debian/Ubuntu”
دستور جستجو خروجي شبيه به زير را به همراه خواهد داشت:

Output
Found 21 roles matching your search:

Name Description
—- ———–
alikins.php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
bpresles.php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
entanet_devops.ansible_role_php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
esperdyne.php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
fidanf.php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
frogasia.ansible-role-php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
geerlingguy.php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
icamys.php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
jhu-sheridan-libraries.php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
jibsan94.ansible_php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
KAMI911.ansible_role_php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
monsieurbiz.geerlingguy_php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
nesh-younify.ansible-role-php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
net2grid.php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
thom8.ansible-role-php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
v0rts.php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
vahubert.php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
Vaizard.mage_php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
viasite-ansible.php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
vvgelder.ansible-role-php PHP for RedHat/CentOS/Fedora/Debian/Ubuntu.
(END)

اگر نتايج زيادي حاصل شود ، Ansible از دستور less براي خروجي نتايج جستجو استفاده مي كند ، كه تا زماني كه q را فشار دهيد، ترمينال شما را مسدود مي كند. اين كار براي زماني مفيد است كه نتايج جستجو گسترده باشد و شما بايد در ميان آنها صفحه گذاري كنيد ، كه مي توانيد با فشار دادن space اين كار را انجام دهيد.
ما رول geerlingguy.php را براي playbook خود انتخاب خواهيم كرد. اگر مايل هستيد اطلاعات بيشتري درباره رول هايي كه با نتايج جستجوي شما برگشته اند ، بخوانيد ، مي توانيد به صفحه جستجوي Galaxy مراجعه كرده و اسم رول مورد نظر خود را در محل نام رول پيست كنيد.
براي دانلود رول براي استفاده در playbook ، از دستور installible-galaxy استفاده مي كنيم:
$ ansible-galaxy install geerlingguy.php
هنگامي كه آن فرمان را اجرا مي كنيد ، بايد خروجي مانند اين را مشاهده كنيد:
Output
– downloading role ‘php’, owned by geerlingguy
– downloading role from https://github.com/geerlingguy/ansible-role-php/archive/3.7.0.tar.gz
– extracting geerlingguy.php to /home/sammy/.ansible/roles/geerlingguy.php
– geerlingguy.php (3.7.0) was installed successfully

اكنون مي توانيم رول را به فايل playbook.yml اضافه كنيم:

– hosts: all
become: true
roles:
– apache
– geerlingguy.php
vars:
– doc_root: /var/www/example
– php_default_version_debian: “7.2”

با قرار دادن رول پس از رول apache، اطمينان مي دهيم كه Apache قبل از تنظيمات مربوط به مكان رول geerlingguy.php ، روي سيستمهاي از راه دور تنظيم و پيكربندي شده است. بسته به نحوه رفتار سرور مجازي هاي از راه دور ، مي توانيم رول هاي mysql و wordpress را نيز به هر ترتيبي كه انتخاب مي كنيم ، شامل شويم.
اجراي ansible-playbook playbook.yml با رول Galaxy اضافه شده منجر به خروجي زير خواهد شد:
Output
PLAY [all] *********************************************************************

TASK [Gathering Facts] *********************************************************
ok: [64.225.15.1]

TASK [apache : Update apt] *****************************************************
changed: [64.225.15.1]

TASK [apache : Install Apache] *************************************************
changed: [64.225.15.1]

TASK [apache : Install modsecurity] ********************************************
changed: [64.225.15.1]

TASK [apache : Create custom document root] ************************************
changed: [64.225.15.1]

TASK [apache : Set up HTML file] ***********************************************
changed: [64.225.15.1]

TASK [apache : Set up Apache virtual host file] ********************************
changed: [64.225.15.1]

TASK [geerlingguy.php : Include OS-specific variables.] ************************
ok: [64.225.15.1]

TASK [geerlingguy.php : Define php_packages.] **********************************
ok: [64.225.15.1]

. . .

PLAY RECAP *********************************************************************
64.225.15.1 : ok=37 changed=15 unreachable=0 failed=0
(END)

نتيجه
رول هاي Ansible يك روش عالي براي ساختاردهي و تعريف چگونگي سرور مجازي هاي شما ميباشد. حتي اگر فقط به playbooks براي هر يك از سرور مجازي هاي خود تكيه كرده ايد ، ارزشش را دارد كه نحوه استفاده از آنها را بياموزيد. اگر قصد استفاده گسترده از Ansible را داريد ، رول ها پيكربندي سطح ميزبان را جدا از وظيفه خود نگه مي دارند ، و اطمينان حاصل مي كنند كه كد Ansible شما تميز و خوانا است. از همه مهمتر ، رول ها به شما امكان مي دهند تا به راحتي از كد استفاده كرده و به اشتراك بگذاريد و تغييرات خود را به صورت كنترل شده و مدولار پياده سازي كنيد.


برچسب: ،
بازدید:

ادامه مطلب

نوشته شده: ۸ بهمن ۱۳۹۸ساعت: ۰۱:۲۷:۵۰ توسط:server موضوع:

نحوه پيكربندي يك خوشه Galera با MySQL در سرورهاي اوبونتو 18.04

مقدمه
خوشه بندي با توزيع تغييرات در سرورهاي مختلف ، دسترس پذيري بالايي به پايگاه داده شما مي دهد. در صورت عدم موفقيت يكي از موارد ، بقيه سريعاً براي سرويس دهي در دسترس هستند.
خوشه ها در دو پيكربندي كلي ، فعال-منفعل و فعال-فعال ارائه مي شوند. در خوشه هاي فعال منفعل، همه نوشتن ها بر روي يك سرور مجازي فعال انجام مي شود و سپس در يك يا چند سرور مجازي منفعل كپي مي شوند كه آماده هستند فقط در صورت خرابي سرور مجازي فعال ، به كار بيفتند. برخي از خوشه هاي فعال منفعل نيز امكان انجام SELECT بر روي گره هاي منفعل را مي دهند. در يك خوشه فعال فعال ، هر گره خواندن -نوشتن است و تغيير ايجاد شده در يكي ، براي همه تكرار مي شود.
MySQL يك سيستم مديريت پايگاه داده رابطه اي منبع باز است كه يك انتخاب محبوب براي پايگاه داده هاي SQL ميباشد. Galera يك راه حل خوشه بندي بانك اطلاعاتي است كه شما را قادر مي سازد با استفاده از همانند سازي همزمان ، خوشه هاي چند مستر تنظيم كنيد. Galera به طور خودكار داده ها را بر روي گره هاي مختلف به صورت همگام سازي مديريت ميكند در حالي كه به شما امكان مي دهد براي هر كدام از گره هاي موجود در اين گروه ، درخواست هايي را بخوانيد و بنويسيد. مي توانيد اطلاعات بيشتري در مورد Galera در صفحه مطالب رسمي كسب كنيد.
در اين راهنما ، يك خوشه فعال MySQL Galera را پيكربندي مي كنيد. براي اهداف نمايشي ، سه دراپلت Ubuntu 18.04 را كه به عنوان گره در خوشه عمل مي كنند ، پيكربندي كرده و آزمايش مي كنيد. اين مقدار گره كوچكترين خوشه قابل تنظيم است.
پيش نيازها
براي دنبال كردن مطلب ، علاوه بر موارد زير ، به يك حساب vpsgol نيز نياز داريد:
سه دراپلت Ubuntu 18.04 با شبكه خصوصي فعال شده كه هر كدام داراي يك كاربر غير ريشه با امتيازات sudo هستند.
براي راه اندازي شبكه هاي خصوصي در سه دراپلت ، راهنماي راه اندازي سريع شبكه را دنبال كنيد.
براي كمك به راه اندازي يك كاربر غير ريشه با امتيازات sudo ، راهنماي اوليه راه اندازي سرور مجازي ما با آموزش اوبونتو 18.04 را دنبال كنيد.
در حالي كه مراحل اين آموزش براي دراپلت هاي vpsgol نوشته و تست شده است ، بسياري از آنها در سرورهاي غير vpsgol نيز كه شبكه هاي خصوصي را فعال مي كنند كاربرد دارند.
مرحله 1 – اضافه كردن منابع MySQL به همه سرورها
در اين مرحله منابع بسته MySQL و Galera را به هر سه سرور مجازي خود اضافه مي كنيد تا بتوانيد نسخه صحيح MySQL و Galera مورد استفاده در اين آموزش را نصب كنيد.

توجه: Codership ، شركت پشتيبان خوشه Galera ، منبع Galera را حفظ مي كند ، اما توجه داشته باشيد كه همه منابع خارجي قابل اعتماد نيستند. مطمئن شويد كه فقط از منابع معتبر نصب كنيد.
در اين آموزش از MySQL نسخه 5.7 استفاده خواهيد كرد. كار را با اضافه كردن منبع خارجي اوبونتو كه توسط پروژه Galera براي سه سرور مجازي شما ذخيره شده است شروع مي كنيد.
پس از به روزرساني منابع هر سه سرور مجازي ، شما مي توانيد MySQL را به همراه Galera نصب كنيد.
ابتدا ، در هر سه سرور مجازي خود ، كليد منبع Galera را با دستور apt-key اضافه كنيد ، كه مدير بسته APT براي تأييد صحت اين بسته از آن استفاده مي كند:
$ sudo apt-key adv –keyserver keyserver.ubuntu.com –recv BC19DDBA
بعد از چند ثانيه ، خروجي زير را دريافت خواهيد كرد:
Executing: /tmp/apt-key-gpghome.RG5cTZjQo0/gpg.1.sh –keyserver keyserver.ubuntu.com –recv BC19DDBA
gpg: key D669017EBC19DDBA: public key “Codership Oy ” imported
gpg: Total number processed: 1
gpg: imported: 1

پس از داشتن كليد قابل اعتماد در بانك اطلاعاتي هر سرور مجازي ، مي توانيد منابع را اضافه كنيد. براي اين كار ، يك فايل جديد به نام galera.list را در فهرست /etc/apt/source.list.d/ هر سرور مجازي ايجاد كنيد:
$ sudo nano /etc/apt/sources.list.d/galera.list
در ويرايشگر متن ، سطرهاي زير را اضافه كنيد ، كه منابع مناسب را در اختيار مدير بسته APT قرار مي دهد:
/etc/apt/sources.list.d/galera.list
deb http://releases.galeracluster.com/mysql-wsrep-5.7/ubuntu bionic main
deb http://releases.galeracluster.com/galera-3/ubuntu bionic main

فايل ها را روي هر سرور مجازي ذخيره كنيد و ببنديد (CTRL + X ، Y ، سپس ENTER را فشار دهيد)
منابع codership اكنون براي هر سه سرور مجازي شما در دسترس است. با اين حال ، مهم است كه به apt دستور دهيد كه منابع Codership را به ديگر منابع ترجيح دهد تا از نصب نسخه هاي پچ شده نرم افزار مورد نياز براي ايجاد يك خوشه Galera اطمينان حاصل شود. براي اين كار ، فايل جديد ديگري به نام galera.pref را در فهرست /etc/apt/preferences.d/ هر سرور مجازي ايجاد كنيد:

$ sudo nano /etc/apt/preferences.d/galera.pref
خطوط زير را به ويرايشگر متن اضافه كنيد:
/etc/apt/preferences.d/galera.pref
# Prefer Codership repository
Package: *
Pin: origin releases.galeracluster.com
Pin-Priority: 1001

آن فايل را ذخيره كرده و ببنديد ، سپس دستور زير را روي هر سرور مجازي اجرا كنيد تا مانيفست بسته از منابع جديد را شامل شود:
$sudo apt update
اكنون كه منبع بسته را با موفقيت روي هر سه سرور مجازي خود اضافه كرديد ، آماده هستيد MySQL را در بخش بعدي نصب كنيد.
مرحله 2 – نصب MySQL در تمام سرورها
در اين مرحله بسته MySQL را روي سه سرور مجازي خود نصب خواهيد كرد.
براي نصب نسخه MySQL پچ شده براي كار با Galera ، و همچنين بسته Galera ، دستور زير را در هر سه سرور مجازي اجرا كنيد.
$ sudo apt install galera-3 mysql-wsrep-5.7
از شما خواسته مي شود كه تأييد كنيد آيا نصب را ادامه مي دهيد يا خير. Y را وارد كنيد تا نصب ادامه يابد. در حين نصب از شما خواسته مي شود كه يك رمز عبور براي كاربر اجرايي MySQL ايجاد كنيد. يك رمز عبور ايمن تنظيم كنيد و ENTER را براي ادامه فشار دهيد.
پس از نصب MySQL ، مشخصات پيش فرض AppArmor را غيرفعال مي كنيد تا مطابق مطالب مربوطه Galera ، از عملكرد صحيح Galera اطمينان حاصل كنيد. AppArmor يك ماژول هسته براي لينوكس است كه عملكرد كنترل دسترسي را براي خدمات از طريق پروفايل هاي امنيتي فراهم مي كند.
AppArmor را با اجراي دستور زير در هر سرور مجازي غيرفعال كنيد:
$ sudo ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable/
اين دستور يك پيوند نمادين از پروفايل MySQL را به فهرست disable اضافه مي كند ، كه نمايه را در بوت غيرفعال مي كند.
سپس دستور زير را اجرا كنيد تا تعريف MySQL را كه قبلاً در هسته بارگذاري شده است حذف كنيد.
$ sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.mysqld
پس از نصب MySQL و نمايه AppArmor در اولين سرور مجازي خود ، اين مراحل را براي دو سرور مجازي ديگر خود تكرار كنيد.

اكنون كه MySQL را با موفقيت در هر سه سرور مجازي نصب كرديد ، مي توانيد در قسمت بعدي به مرحله تنظيمات برويد.
مرحله 3 – پيكربندي گره اول
در اين مرحله اولين گره خود را پيكربندي مي كنيد. هر گره در خوشه نياز به پيكربندي تقريباً يكسان دارد. به همين دليل تمام پيكربندي هاي موجود در دستگاه اول خود را انجام داده و سپس آن را در گره هاي ديگر كپي مي كنيد.
به طور پيش فرض ، MySQL پيكربندي شده است تا دايركتوري /etc/mysql/conf.d را بررسي كند تا تنظيمات اضافي پيكربندي را از فايل هاي منتهي به .cnf دريافت كند. در اولين سرور مجازي خود ، با همه دستورالعملهاي مربوط به خوشه ، يك فايل در اين فهرست ايجاد كنيد:
Glara-node01$ sudo nano /etc/mysql/conf.d/galera.cnf
پيكربندي زير را در فايل اضافه كنيد. پيكربندي گزينه هاي مختلف خوشه اي ، جزئيات مربوط به سرور مجازي فعلي و ساير سرورهاي موجود در خوشه و تنظيمات مربوط به همانند سازي را مشخص مي كند. توجه داشته باشيد كه آدرسهاي IP موجود در پيكربندي ، آدرسهاي خصوصي سرورهاي مربوطه شما هستند. خطوط هايلايت شده را با آدرس هاي IP مناسب جايگزين كنيد.
/etc/mysql/conf.d/galera.cnf
[mysqld]
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Galera Cluster Configuration
wsrep_cluster_name=”test_cluster”
wsrep_cluster_address=”gcomm://First_Node_IP,Second_Node_IP,Third_Node_IP”

# Galera Synchronization Configuration
wsrep_sst_method=rsync

# Galera Node Configuration
wsrep_node_address=”This_Node_IP”
wsrep_node_name=”This_Node_Name”

بخش اول تنظيمات MySQL را اصلاح و يا دوباره اجرا مي كند كه باعث مي شود خوشه به درستي كار كند. به عنوان مثال ، Galera با MyISAM يا موتورهاي ذخيره سازي غير معاملاتي مشابه كار نخواهد كرد ، و mysqld نبايد به آدرس IP مربوط به localhost محدود شود. مي توانيد در مورد تنظيمات با جزئيات بيشتري در صفحه پيكربندي سيستم Galera Cluster اطلاعات كسب كنيد.
بخش “پيكربندي ارائه دهنده Galera” اجزاي MySQL را كه يك API همانند سازي WritSet را ارائه مي دهد ، پيكربندي مي كند. كه در اين مورد براي شما Galera است ، زيرا Galera يك ارائه دهنده wsrep (WritSet Replication) است. شما براي پيكربندي محيط تكثير اوليه ، پارامترهاي كلي را تعيين مي كنيد. اين نياز به هيچگونه سفارشي سازي ندارد ، اما مي توانيد در مورد گزينه هاي پيكربندي Galera در مطالب موجود اطلاعات بيشتري كسب كنيد.
بخش “تنظيمات خوشه Galera” ، خوشه را تعريف مي كند ، اعضاي خوشه را با آدرس IP يا نام دامنه قابل تعيين شناسايي مي كند و نامي را براي اين خوشه ايجاد مي كند تا از عضويت در گروه صحيح اطمينان حاصل كند. مي توانيد wsrep_cluster_name را به چيزي با معني تر از test_cluster تغيير دهيد يا آن را به همين صورت رها كنيد ، اما بايد wsrep_cluster_address را با آدرس هاي IP خصوصي سه سرور مجازي خود به روز كنيد.
بخش پيكربندي همگام سازي Galeraچگونگي ارتباط و همگام سازي داده هاي خوشه بين اعضا را تعريف مي شود. اين فقط براي تبديل وضعيت در هنگامي كه يك گره به صورت آنلاين درميايد، استفاده مي شود. براي راه اندازي اوليه خود ، شما از rsync استفاده مي كنيد ، زيرا معمولاً در دسترس تر است و آنچه را كه اكنون به آن نياز داريد انجام مي دهد.
قسمت پيكربندي گره Galera آدرس IP و نام سرور مجازي فعلي را مشخص مي كند. اين كار هنگام تلاش براي تشخيص مشكلات موجود در ورودها و براي ارجاع به هر سرور مجازي به روش هاي مختلف مفيد است.wsrep_node_address بايد با آدرس دستگاهي كه در آن قرار داريد مطابقت داشته باشد ، اما مي توانيد هر نامي را كه مي خواهيد انتخاب كنيد تا به شما در شناسايي گره در فايل هاي log كمك كند.
هنگامي كه از فايل پيكربندي خوشه خود راضي شديد ، محتويات را در كليپ بورد خود كپي كنيد ، سپس فايل را ذخيره كنيد و ببنديد.
اكنون كه اولين گره خود را با موفقيت پيكربندي كرده ايد ، مي توانيد در قسمت بعدي پيكربندي گره هاي باقي مانده را انجام دهيد.
مرحله 4 – پيكربندي گره هاي باقي مانده
در اين مرحله ، دو گره باقي مانده را پيكربندي مي كنيد. در گره دوم ، فايل پيكربندي را باز كنيد:
Glara-node02$ sudo nano /etc/mysql/conf.d/galera.cnf
پيكربندي خود را از اولين گره كپي كنيد و سپس Galera Node Configuration را به روز كنيد تا از آدرس IP يا نام دامنه مناسب براي گره خاصي كه تنظيم مي كنيد استفاده كنيد. سرانجام ، نام آن را به روز كنيد ، كه مي توانيد هر چيزي كه به شما در شناسايي گره موجود در فايل هاي log كمك ميكند ، استفاده نماييد:
/etc/mysql/conf.d/galera.cnf
. . .
# Galera Node Configuration
wsrep_node_address=”This_Node_IP”
wsrep_node_name=”This_Node_Name”
. . .

فايل را ذخيره كنيد و از آن خارج شويد.
پس از اتمام اين مراحل ، آنها را بر روي گره سوم تكرار كنيد.
شما تقريباً آماده هستيد تا اين خوشه را به كار بگيريد ، اما قبل از انجام اين كار ، اطمينان حاصل كنيد كه درگاه هاي مناسب در فايروال شما باز است.
مرحله 5 – باز كردن فايروال در هر سرور مجازي
در اين مرحله فايروال خود را پيكربندي مي كنيد تا درگاه هاي مورد نياز براي ارتباط بين گره اي باز باشد. در هر سرور مجازي ، وضعيت اجراي فايروال را با اجراي دستور زير بررسي كنيد:
$ sudo ufw status
در اين حالت ، فقط SSH مجاز است از طريق:
Output
Status: active

To Action From
— —— —-
OpenSSH ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)

از آنجا كه فقط ترافيك SSH در اين مورد مجاز است ، لازم است قوانيني را براي ترافيك MySQL و Galera اضافه كنيد. اگر سعي كرديد خوشه را شروع كنيد ، به دليل اين قوانين فايروال با شكست مواجه ميشويد.
Galera مي تواند از چهار پورت استفاده كند:
3306 براي اتصالات مشتري MySQL و انتقال اسنپ شات كه از روش mysqldump استفاده مي كنند.
4567 براي ترافيك كپي خوشه Galera. همانندسازي Multicast هم از تبديل UDP و هم TCP در اين پورت استفاده مي كند.
4568 براي تبديل وضعيت افزايشي.
4444 براي همه موارد ديگر انتقال اسنپ شات.
در اين مثال ، هر زمان كه ستاپ خود را انجام داديد ، هر چهار پورت را باز خواهيد كرد. هنگامي كه تأييد كرديد كه عمليات كپي در حال كار كردن است ، بهتر است پورت هايي را كه در واقع استفاده نمي كنيد ببنديد و ترافيك را فقط به سرورهاي موجود در خوشه محدود كنيد.
درگاه ها را با دستورات زير باز كنيد:
$ sudo ufw allow 3306,4567,4568,4444/tcp
$ sudo ufw allow 4567/udp

توجه: بسته به آنچه در سرورهاي شما اجرا مي شود ، ممكن است لازم باشد سريعاً دسترسي را محدود كنيد. راهنماي UFW Essentials: قوانين و دستورات معمول فايروال مي تواند در اين امر كمك كند.
بعد از تنظيم فايروال خود در گره اول ، همان تنظيمات فايروال را در گره دوم و سوم ايجاد كنيد.
اكنون كه فايروال ها را با موفقيت پيكربندي كرده ايد ، آماده هستيد تا در مرحله بعدي خوشه را شروع كنيد.
مرحله 6 – شروع خوشه
در اين مرحله خوشه MySQL Galera خود را شروع مي كنيد. اما ابتدا سرويس سيستمي MySQL را فعال مي كنيد ، به طوري كه هر بار كه سرور مجازي ريبوت ميشود ، MySQL به طور خودكار شروع مي شود.
MySQL را فعال كنيد تا در هر سه سرور مجازي در حين بوت شروع به كار كند
براي فعال كردن سرويس سيستمي MySQL از دستور زير در هر سه سرور مجازي استفاده كنيد:
$ sudo systemctl enable mysql
خروجي زير را مشاهده خواهيد كرد كه نشان مي دهد اين سرويس با موفقيت به ليست خدمات استارآپ مرتبط شده است:
Output
Created symlink /etc/systemd/system/multi-user.target.wants/mysql.service → /lib/systemd/system/mysql.service.

اكنون كه mysql را فعال كرده ايد كه در بوت همه سرورها شروع به كار كند ، آماده هستيد تا اين خوشه را ارتقا دهيد.
گره اول را بالا بياوريد
براي بالا بردن گره اول ، بايد از يك اسكريپت راه اندازي ويژه استفاده كنيد. روشي كه خوشه خود را پيكربندي كرده ايد ، هر گره اي كه آنلاين مي شود سعي مي كند به حداقل يك گره ديگر كه در فايل galera.cnf مشخص شده است وصل شود تا حالت اوليه خود را بدست آورد. بدون استفاده از اسكريپت mysqld_bootstrap كه به systemd اجازه مي دهد از پارامتر –wsrep-new-cluster عبور كند ، يك systemctl start mysql معمول با شكست مواجه ميشود زيرا هيچ گره اي براي اتصال گره اول به آن وجود ندارد.
دستور زير را در اولين سرور مجازي خود اجرا كنيد:
Galera-node-01$ sudo mysqld_bootstrap
اين دستور هيچ گونه خروجي را در اجراي موفقيت آميز نشان نمي دهد. با موفقيت اين اسكريپت ، گره به عنوان بخشي از خوشه ثبت مي شود و مي توانيد آن را با دستور زير مشاهده كنيد:
Galera-node-01$ mysql -u root -p -e “SHOW STATUS LIKE ‘wsrep_cluster_size'”
پس از وارد كردن رمز عبور خود ، خروجي زير را مشاهده خواهيد كرد كه نشان مي دهد يك گره در خوشه وجود دارد:
Output
+——————–+——-+
| Variable_name | Value |
+——————–+——-+
| wsrep_cluster_size | 1 |
+——————–+——-+

در گره هاي باقيمانده مي توانيد به طور عادي mysql را شروع كنيد. آنها به جستجوي هر يك از اعضاي ليست خوشه هاي آنلاين مي پردازند و وقتي يكي را پيدا كردند به اين خوشه مي پيوندند.
گره دوم را بالا بياوريد
اكنون مي توانيد گره دوم را بالا بياوريد. mysql را شروع كنيد:
Galera-node-02$ sudo systemctl start mysql

هيچ خروجي در اجراي موفق نمايش داده نمي شود. با آنلاين شدن هر گره ، اندازه خوشه افزايش مي يابد:
Galera-node-02$ mysql -u root -p -e “SHOW STATUS LIKE ‘wsrep_cluster_size'”
خروجي زير را خواهيد ديد كه نشان مي دهد كه گره دوم به خوشه پيوسته است و در كل دو گره وجود دارد.
Output
+——————–+——-+
| Variable_name | Value |
+——————–+——-+
| wsrep_cluster_size | 2 |
+——————–+——-+

گره سوم را بالا ببريد
اكنون زمان آن رسيده كه گره سوم را بالا ببريدم. Mysql را شروع كنيد:
Galera-node-03$ sudo systemctl start mysql
دستور زير را براي يافتن اندازه خوشه اجرا كنيد:
Galera-node-03$ mysql -u root -p -e “SHOW STATUS LIKE ‘wsrep_cluster_size'”
خروجي زير را مشاهده خواهيد كرد كه نشان مي دهد گره سوم به خوشه پيوسته است و تعداد كل گره هاي موجود در خوشه سه است.
Output
+——————–+——-+
| Variable_name | Value |
+——————–+——-+
| wsrep_cluster_size | 3 |
+——————–+——-+

در اين مرحله ، كليه خوشه ها بصورت آنلاين و با موفقيت ارتباط برقرار مي كنند. در مرحله بعد مي توانيد با آزمايش همانند سازي در بخش زير ، از تنظيم كار اطمينان حاصل كنيد.
مرحله 7 – تست همانندسازي
شما مراحل تا اين مرحله طي كرده ايد تا خوشه شما بتواند كپي كردن را از هر گره به گره ديگر كه همانندسازي فعال-فعال ناميده ميشود، انجام دهد. در اين مرحله ، شما تست خواهيد كرد و ميبينيد كه آيا همانند سازي همانطور كه انتظار مي رود، كار مي كند.
در گره اول بنويسيد
با ايجاد تغيير در پايگاه داده در اولين گره خود شروع خواهيد كرد. دستورات زير يك پايگاه داده به نام playground و يك جدول درون اين پايگاه داده با نام equipment ايجاد مي كنند.
Galera-node-01$ mysql -u root -p -e ‘CREATE DATABASE playground;
Galera-node-01$ CREATE TABLE playground.equipment ( id INT NOT NULL AUTO_INCREMENT, type VARCHAR(50), quant INT, color VARCHAR(25), PRIMARY KEY(id));
Galera-node-01$ INSERT INTO playground.equipment (type, quant, color) VALUES (“slide”, 2, “blue”);’
در دستور قبلي ، عبارت CREATE DATABASE يك ديتابيس با نام playground ايجاد مي كند. عبارت CREATE يك جدول به نام equipment  درون playground  ايجاد مي كند كه داراي يك ستون شناسه افزايش خودكار به نام id و ساير ستون ها است. ستون type ، ستون quant و ستون color به ترتيب براي ذخيره نوع و كميت و رنگ تجهيزات تعريف شده است. عبارت INSERT يك ورودي از نوع اسلايد ، كميت 2 و رنگ آبي را درج مي كند.
اكنون يك مقدار در جدول خود داريد.
داده ها را در گره دوم بخوانيد و بنويسيد.
در مرحله بعدي ، به منظور بررسي اينكه كپي در حال كار كردن است ، به گره دوم نگاه كنيد:
Galera-node-02$ mysql -u root -p -e ‘SELECT * FROM playground.equipment;’
داده هايي كه در گره اول وارد كرده ايد در مرحله دوم قابل مشاهده خواهد بود ، كه اثبات ميكند اين همانندسازي كار مي كند:
Output
+—-+——-+——-+——-+
| id | type | quant | color |
+—-+——-+——-+——-+
| 1 | slide | 2 | blue |
+—-+——-+——-+——-+
از همين گره ، داده ها را در خوشه بنويسيد:
Galera-node-02$ mysql -u root -p -e ‘INSERT INTO playground.equipment (type, quant, color) VALUES (“swing”, 10, “yellow”);’

در گره سوم بخوانيد و بنويسيد
از گره سوم ، مي توانيد با فراخواني مجدد جدول ، تمام اين داده ها را بخوانيد:
Galera-node-03$ mysql -u root -p -e ‘SELECT * FROM playground.equipment;’
خروجي زير را نشان مي دهد كه دو رديف را نشان مي دهد:
Output
+—-+——-+——-+——–+
| id | type | quant | color |
+—-+——-+——-+——–+
| 1 | slide | 2 | blue |
| 2 | swing | 10 | yellow |
+—-+——-+——-+——–+
باز هم ، مي توانيد مقدار ديگري از اين گره اضافه كنيد:
Galera-node-03$ mysql -u root -p -e ‘INSERT INTO playground.equipment (type, quant, color) VALUES (“seesaw”, 3, “green”);’
در گره اول بخوانيد
با بازگشت به گره اول ، مي توانيد تأييد كنيد كه داده هاي شما در همه جا در دسترس است:
Galera-node-01$ mysql -u root -p -e ‘SELECT * FROM playground.equipment;’
خروجي زير را مشاهده خواهيد كرد ، كه نشان مي دهد رديف ها در گره اول موجود هستند.
Output
+—-+——–+——-+——–+
| id | type | quant | color |
+—-+——–+——-+——–+
| 1 | slide | 2 | blue |
| 2 | swing | 10 | yellow |
| 3 | seesaw | 3 | green |
+—-+——–+——-+——–+

اكنون با موفقيت تأييد كرده ايد كه مي توانيد در همه گره ها بنويسيد و اين تكرار به درستي انجام مي شود.
نتيجه
در اين مرحله ، شما يك خوشه آزمايش Galera سه گره اي پيكربندي كرده ايد. اگر قصد داريد از يك خوشه Galera در يك وضعيت توليد استفاده كنيد ، توصيه مي شود با حداقل كمتر از پنج گره شروع نكنيد.
قبل از استفاده از توليد ، بهتر است به برخي از عوامل تبديل اسنپ شات (sst) حالات ديگر از جمله xtrabackup نگاهي بيندازيد ، كه به شما امكان مي دهد گره هاي جديد را به سرعت و بدون ايجاد اختلال در گره هاي فعال خود تنظيم كنيد. اين كار بر كپي كردن واقعي تأثير نمي گذارد، اما وقتي گره ها شروع مي شوند اهميت پيدا ميكند.
همچنين ممكن است به راه حل هاي خوشه بندي ديگري براي MySQL علاقه مند باشيد ، در اين صورت مي توانيد نحوه آموزش ايجاد يك خوشه MySQL چند گره را در Ubuntu 18.04 ببينيد. اگر مي خواهيد راه حل پايگاه داده مديريت شده را امتحان كنيد ، به مستندات پايگاه داده هاي مديريت شده vpsgol مراجعه كنيد.


برچسب: ،
بازدید:

ادامه مطلب

نوشته شده: ۸ بهمن ۱۳۹۸ساعت: ۰۱:۲۷:۲۲ توسط:server موضوع:

نحوه تهيه نسخه پشتيبان و بازيابي يك خوشه Kubernetes در vpsgol با استفاده از Velero

مقدمه
Velero يك ابزار پشتيبان مناسب براي خوشه هاي Kubernetes است كه موارد Kubernetes را براي ذخيره سازي مورد به مورد، فشرده سازي و پشتيبان گيري مي كند. همچنين با استفاده از ويژگي هاي اسنپ شات ذخيره سازي واحد ارائه دهنده cloud ، عكس هايي از واليوم هاي مداوم خوشه شما مي گيرد و مي تواند موارد و واليوم هاي ماندگار خوشه را به حالت قبلي بازگرداند.
افزونه vpsgol Velero به شما امكان مي دهد تا از حافظه بلوك vpsgol استفاده كنيد تا از واليوم هاي ماندگار اسنپ شات بگيريد و فضايي به شما ميدهد تا از موارد Kubernetes بك آپ تهيه كنيد. در هنگام اجراي يك خوشه Kubernetes در vpsgol ، اين به شما امكان مي دهد تا به سرعت از وضعيت خوشه خود نسخه پشتيبان تهيه كرده و در صورت بروز مشكل بازيابي كنيد.
در اين آموزش ابزار خط فرمان velero را روي يك دستگاه محلي تنظيم و پيكربندي مي كنيم و مؤلفه سرور مجازي را در خوشه Kubernetes خود مستقر مي كنيم. سپس يك نمونه از برنامه Nginx را استفاده مي كنيم كه از يك واليوم پايدار براي ورود به سيستم استفاده مي كند و سپس يك سناريوي بازيابي مشكل را شبيه سازي مي كند.
پيش نيازها
قبل از شروع اين آموزش ، موارد زير را بايد در اختيار داشته باشيد:
در رايانه محلي خود:
⦁ ابزار خط فرمان kubectl ، پيكربندي شده بايد تا به خوشه شما متصل شود. مي توانيد اطلاعات بيشتري در مورد نصب و پيكربندي ر در مطالب Kubernetes بخوانيد.
⦁ ابزار خط فرمان gitكه مي توانيد نحوه نصب git را در شروع با Git بياموزيد.
در حساب vpsgol خود:
⦁ يك خوشه vpsgol Kubernetes يا يك خوشه Kubernetes (نسخه 1.7.5 يا بالاتر) در دراپلت هاي vpsgol.
⦁ سرور DNS كه در داخل خوشه شما قرار دارد. اگر از vpsgol Kubernetes استفاده مي كنيد ، اين به طور پيش فرض اجرا مي شود. براي كسب اطلاعات بيشتر در مورد پيكربندي يك سرويس DNS Kubernetes ، از ⦁ Customizing DNS Service در مطالب رسمي Kuberentes كمك بگيريد.
⦁ فضاي vpsgol كه موارد پشتيبان گرفته شده Kubernetes شما را ذخيره مي كند. براي يادگيري نحوه ايجاد يك فضا ، از  ⦁ the Spaces product documentation كمك بگيريد.
⦁ يك جفت كليد دسترسي براي vpsgol Space. براي يادگيري نحوه ايجاد مجموعه اي از كليدهاي دستيابي ، از ⦁ How to Manage Administrative Access to Spaces كمك بگيريد.
⦁ يك نشانه دسترسي شخصي براي استفاده با vpsgol API. براي يادگيري نحوه ايجاد يك نشانه دسترسي شخصي ، از ⦁ How to Manage Administrative Access to Spaces كمك بگيريد. اطمينان حاصل كنيد كه توكن ايجاد شده يا استفاده شده از مجوزهاي خواندن / نوشتن و يا اسنپ شات استفاده نميكند.
پس از تنظيم همه اين موارد ، آماده شروع كار با اين راهنما هستيد.

مرحله 1 – نصب مشتري Velero
ابزار پشتيبان گيري Velero شامل يك مشتري نصب شده بر روي رايانه محلي شما و يك سرور مجازي است كه در خوشه Kubernetes شما اجرا مي شود. براي شروع ، مشتري محلي Velero را نصب خواهيم كرد.
در مرورگر وب خود ، به صفحه منتشر شده repo Velero GitHub برويد ، نسخه مربوط به سيستم عامل و معماري سيستم خود را پيدا كنيد و آدرس پيوند را كپي كنيد. براي اهداف اين راهنما ، ما از يك سرور مجازي اوبونتو 18.04 در يك پردازنده x86-64 (يا AMD64) به عنوان دستگاه محلي خود و نسخه Velero v1.2.0 استفاده خواهيم كرد.
توجه: براي دنبال كردن اين راهنما ، بايد v1.2.0 از مشتري Velero را دانلود و نصب كنيد.
سپس ، از خط فرمان روي رايانه محلي خود ، به دايركتوري موقت / tmp برويد و cd را در آن قرار دهيد:
$cd / tmp
از wget و پيوندي كه قبلاً كپي كرده ايد براي دانلود تاربال نسخه استفاده كنيد:
$wget https: // link_copied_from_release_page
پس از اتمام دانلود ، تاربال را با استفاده از tar اكستركت كنيد (توجه داشته باشيد كه نام فايل بسته به نسخه منتشر شده و سيستم عامل شما ممكن است متفاوت باشد):
$tar -xvzf velero-v1.2.0-linux-amd64.tar.gz
ديركتوري / tmp اكنون بايد ديركتوري اكستركت شده velero-v1.2.0-linux-amd64 و همچنين تاربلي كه اخيراً دانلود كرده ايد ، را شامل شود.
تأييد كنيد كه مي توانيد مشتري velero را با اجراي باينري راه اندازي كنيد:
$./velero-v1.2.0-linux-amd64/velero help
شما بايد خروجي راهنمايي زير را مشاهده كنيد:
Output
Velero is a tool for managing disaster recovery, specifically for Kubernetes
cluster resources. It provides a simple, configurable, and operationally robust
way to back up your application state and associated data.

If you’re familiar with kubectl, Velero supports a similar model, allowing you to
execute commands such as ‘velero get backup’ and ‘velero create schedule’. The same
operations can also be performed as ‘velero backup get’ and ‘velero schedule create’.

Usage:
velero [command]

Available Commands:
backup Work with backups
backup-location Work with backup storage locations
bug Report a Velero bug
client Velero client related commands
completion Output shell completion code for the specified shell (bash or zsh)
create Create velero resources
delete Delete velero resources
describe Describe velero resources
get Get velero resources
help Help about any command
install Install Velero
plugin Work with plugins
restic Work with restic
restore Work with restores
schedule Work with schedules
snapshot-location Work with snapshot locations
version Print the velero version and associated image
. . .

در اين مرحله بايد velero  قابل اجرا را از ديركتوري موقت tmp  خارج كنيد و آن را به PATH اضافه كنيد. براي افزودن آن به PATH روي يك سيستم اوبونتو كافيست آن را در /usr/local/bin كپي كنيد:
$sudo mv velero-v1.2.0-linux-amd64/velero /usr/local/bin/velero
مرحله 2 – پيكربندي اطلاعات سري
قبل از تنظيم مؤلفه سرور مجازي Velero ، بايد كليدهاي vpsgol Spaces و نشانه هاي API خود را آماده كنيد. مجدداً با استفاده از دستور cd به ديركتوري موقت / tmp برويد:
$ cd / tmp
اكنون يك نسخه از افزونه Velero را براي vpsgol دانلود خواهيم كرد. به صفحه انتشار نسخه هاي Github افزونه برويد و پيوندهايي كه به.tar.gz ختم ميشوند را كپي كنيد.
از wget و پيوندي كه قبلاً كپي كرده ايد براي دانلود تاربال نسخه استفاده كنيد:
$wget https: // link_copied_from_release_page
پس از اتمام دانلود ، تاربل را با استفاده از tar اكستركت كنيد (دوباره توجه داشته باشيد كه نام فايل بسته به نسخه منتشر شده ممكن است متفاوت باشد):
$tar -xvzf v1.0.0.tar.gz
ديركتوري / tmp اكنون بايد پوشه velero-plugin-1.0.0 اكستركت شده و همچنين تاربل كه اخيراً دانلود كرده ايد ، را شامل شود.
سپس cd را در دايركتوري velero-plugin-1.0.0 وارد ميكنيم:
$ cd velero-plugin-1.0.0
اكنون مي توانيم كليدهاي دسترسي را براي vpsgol Space و نشانه API براي استفاده به عنوان Kubernetes Secret ذخيره كنيم. ابتدا با استفاده از ويرايشگر مورد علاقه خود ، فايل examples/cloud-credentials را باز كنيد.
⦁ $ nano examples/cloud-credential
پرونده به شرح زير خواهد بود:
/tmp/velero-plugin-1.0.0/examples/cloud-credentials
[default]
aws_access_key_id=
aws_secret_access_key=

براي استفاده از كليدهاي vpsgol Spaces ، “متغيرهاي” و را ويرايش كنيد. حتماً كاراكترهاي < و > را حذف كنيد.
مرحله بعدي ويرايش فايل 01-velero-secret.patch.yaml است به گونه اي كه شامل نشانه API vpsgol شما باشد. پرونده را در ويرايشگر مورد علاقه خود باز كنيد:

⦁ $ nano examples/01-velero-secret.patch.yaml

مي بايست شبيه به اين باشه:

apiVersion: v1
kind: Secret
stringData:
vpsgol_token:
type: Opaque

براي استفاده از ، كل مكان نگهدار را تغيير دهيد. خط بايد چيزي شبيه به vpsgol_token: 18a0d730c0e0…. باشد: باز هم ، حتماً كاراكترهاي < و > را حذف كنيد.
مرحله 3 – نصب سرور مجازي Velero
نصب Velero شامل تعدادي از موارد Kubernetes است كه همگي براي ايجاد ، برنامه ريزي و مديريت پشتيبان گيري با هم كار مي كنند. velero قابل اجرا كه به تازگي دانلود كرده ايد مي تواند اين موارد را براي شما توليد و نصب كند. دستور نصب velero مراحل آماده سازي اوليه را انجام مي دهد تا براي خوشه شما پشتيبان تهيه شود. به طور خاص:
⦁ يك نام فضا velero ايجاد ميكند.
⦁ حساب سرويس velero را اضافه ميكند.
⦁ قوانين كنترل دسترسي مبتني بر نقش (RBAC) را براي اعطاي مجوز به حساب سرويس velero پيكربندي ميكند.
⦁ تعريف منابع اختصاصي (CRD) را براي منابع خاص Velero نصب ميكند: پشتيبان گيري ، برنامه ريزي، بازيابي ، پيكربندي.
⦁ پلاگين هاي Velero را براي مديريت اسنپ شات و فضاي ذخيره سازي ثبت ميكند.
دستور velero install را با چند گزينه تنظيمات غير پيش فرض اجرا خواهيم كرد. به طور خاص ، شما نياز به ويرايش هر يك از تنظيمات زير در فراخواني واقعي فرمان براي مطابقت با پيكربندي Spaces داريد:
– backup velero-backup: مقدار velero-backups را تغيير دهيد تا با نام فضاي vpsgol Space شما مطابقت داشته باشد. به عنوان مثال اگر فضاي خود را ” backup-bucket ” ناميديد ، اين گزينه به اين شكل است: –bucket backup-bucket
–backup-location-config s3Url=https://nyc3.vpsgolspaces.com,region=nyc3 : URL و منطقه را تغيير دهيد تا مطابق با تنظيمات فضاي شما باشد. به طور خاص ، هر دو بخش nyc3 را ويرايش كنيد تا با منطقه اي كه فضاي شما در آن ميزبان است مطابقت داشته باشد. به عنوان مثال ، اگر فضاي شما در منطقه fra1 ميزباني شود ، اين خط به اين صورت است: –backup-location-config s3Url=https://fra1.vpsgolspaces.com,region=fra1 region=fra1.
شناسه هاي منطقه عبارتند از: nyc3 ، sfo2 ، sgp1 و fra1.
پس از آماده شدن با تنظيمات مناسب مكان bucket و backup ، وقت آن است كه Velero را نصب كنيد. دستور زير را اجرا كنيد ، و در صورت لزوم مقادير خود را جايگزين كنيد:

$velero install
$  –provider velero.io/aws
$ –backup velero backup
$ –plugins velero/velero-plugin-for-aws:v1.0.0,vpsgol/velero-plugin:v1.0.0
$ –backup-location-config s3Url=https://nyc3.vpsgolspaces.com,region=nyc3
$ –use-volume-snapshots=false
$ –secret-file=./examples/cloud-credentials
بايد خروجي زير را مشاهده كنيد:
Output
CustomResourceDefinition/backups.velero.io: attempting to create resource
CustomResourceDefinition/backups.velero.io: created
CustomResourceDefinition/backupstoragelocations.velero.io: attempting to create resource
CustomResourceDefinition/backupstoragelocations.velero.io: created
CustomResourceDefinition/deletebackuprequests.velero.io: attempting to create resource
CustomResourceDefinition/deletebackuprequests.velero.io: created
CustomResourceDefinition/downloadrequests.velero.io: attempting to create resource
CustomResourceDefinition/downloadrequests.velero.io: created
CustomResourceDefinition/podvolumebackups.velero.io: attempting to create resource
CustomResourceDefinition/podvolumebackups.velero.io: created
CustomResourceDefinition/podvolumerestores.velero.io: attempting to create resource
CustomResourceDefinition/podvolumerestores.velero.io: created
CustomResourceDefinition/resticrepositories.velero.io: attempting to create resource
CustomResourceDefinition/resticrepositories.velero.io: created
CustomResourceDefinition/restores.velero.io: attempting to create resource
CustomResourceDefinition/restores.velero.io: created
CustomResourceDefinition/schedules.velero.io: attempting to create resource
CustomResourceDefinition/schedules.velero.io: created
CustomResourceDefinition/serverstatusrequests.velero.io: attempting to create resource
CustomResourceDefinition/serverstatusrequests.velero.io: created
CustomResourceDefinition/volumesnapshotlocations.velero.io: attempting to create resource
CustomResourceDefinition/volumesnapshotlocations.velero.io: created
Waiting for resources to be ready in cluster…
Namespace/velero: attempting to create resource
Namespace/velero: created
ClusterRoleBinding/velero: attempting to create resource
ClusterRoleBinding/velero: created
ServiceAccount/velero: attempting to create resource
ServiceAccount/velero: created
Secret/cloud-credentials: attempting to create resource
Secret/cloud-credentials: created
BackupStorageLocation/default: attempting to create resource
BackupStorageLocation/default: created
Deployment/velero: attempting to create resource
Deployment/velero: created
Velero is installed! ⛵ Use ‘kubectl logs deployment/velero -n velero’ to view the status.

شما ميتوانيد به كارگيري ورودي ها با استفاده از دستور kubect از خروجي را مشاهده كنيد. پس از آماده سازي به كارگيري، ميتوانيد به مرحله بعدي برويد كه پيكربندي سرور مجازي است. به كارگيري موفق شبيه زير خواهد بود (با يك تفاوت ستون AGE):
$ kubectl get deployment/velero –namespace velero
Output
NAME READY UP-TO-DATE AVAILABLE AGE
velero 1/1 1 1 2m

دراين نقطه مولفه سرور مجازي Velero  را در خوشه Kubernetes  به عنوان يك صف آرايي نصب كرده ايد. همچنين كليدهاي فضا را با Velero  و با استفاده از Kubernetes Secret ثبت نموده ايد.

توجه: مي توانيد kubeconfig را كه ابزار خط فرمان velero بايد با فلگ –kubeconfig استفاده كند ، مشخص كنيد. اگر از اين فلگ استفاده نمي كنيد ، velero متغير محيط KUBECONFIG را بررسي كرده و سپس به پيش فرض kubectl  يعني (~/.kube/config) برميگردد.

مرحله 4 – پيكربندي اسنپ شات
هنگامي كه سرور مجازي Velero را نصب كرديم ، گزينه –use-volume-snapshots = false بخشي از دستور بود. از آنجا كه مي خواهيم اسنپ شات از دستگاه هاي ذخيره سازي بلوك موجود در خوشه Kubernetes بگيريم ، بايد به Velero بگوييم كه از پلاگين صحيح براي ذخيره سازي بلوك vpsgol استفاده كند.
دستور زير را اجرا كنيد تا افزونه فعال شود و آن را به عنوان ارائه دهنده اسنپ شات پيش فرض ثبت كنيد:

$velero snapshot-location create default –provider vpsgol.com/velero
خروجي زير را مشاهده خواهيد كرد:
Snapshot volume location “default” configured successfully.

مرحله 5 – اضافه كردن يك نشانه API
در مرحله قبل ، ذخيره بلوك و موارد دخيره را در سرور مجازي Velero ايجاد كرديم. ما افزونه vpsgol / velero: v1.0.0 را با سرور مجازي ثبت كرده ايم و كليدهاي مخفي Spaces را در خوشه نصب كرده ايم.
مرحله آخر افزودن اطلاعات سري cloud-credentials است كه قبلاً براي استفاده از نشانه vpsgol API ما ايجاد كرده ايم. بدون اين نشانه ، افزونه Snapshot قادر به تأييد اعتبار با API vpsgol نخواهد بود.
ما مي توانيم از دستور edit kubectl براي تغيير موضوع آرايش Velero با استفاده از نشانه API استفاده كنيم. با اين حال ، ويرايش موضوعات پيچيده YAML با دست مي تواند خسته كننده و پر خطا باشد. در عوض ، از دستور patch kubectl استفاده خواهيم كرد زيرا Kubernetes از patch موضوعات پشتيباني مي كند. بياييد نگاهي گذرا به مطالب فايل هاي پچ مورد نظر خود بياندازيم.
اولين فايل افزوده examples/01-velero-secret.patch.yaml است كه قبلاً ويرايش كرده ايد. اين براي افزودن نشانه API شما به اطلاعات سري secrets/cloud-credentials طراحي شده است كه از قبل حاوي كليدهاي Spaces شما بود. فايل را cat كنيد:
$cat examples/01-velero-secret.patch.yaml
بايد مانند اين باشد (با نشان شما به جاي نگهدارنده  placeholder):
examples/01-velero-secret.patch.yaml
. . .

apiVersion: v1
kind: Secret
stringData:
vpsgol_token:
type: Opaque

حال بياييد به فايل پچ Deployment نگاه كنيم:
$cat examples/02-velero-deployment.patch.yaml
بايد YAML زير را ببينيد:
examples/02-velero-deployment.patch.yaml
. . .

apiVersion: v1
kind: Deployment
spec:
template:
spec:
containers:
– args:
– server
command:
– /velero
env:
– name: vpsgol_TOKEN
valueFrom:
secretKeyRef:
key: vpsgol_token
name: cloud-credentials
name: velero

اين فايل نشان مي دهد كه ما در حال وصله كردن Deployment’s Pod spec هستيم كه به آن velero گفته مي شود. از آنجا كه اين يك پچ است ، ديگر نيازي به مشخص كردن كل خصوصيات يا ابرداده هاي Kubernetes نيست. در اين حالت ، پياده سازي Velero قبلاً با استفاده از cloud-credentials پيكربندي شده است زيرا دستور نصب velero آن را براي ما ايجاد كرده است. بنابراين ، تمام آنچه كه بايد اين پچ انجام دهد ثبت نام vpsgol_token به عنوان متغير محيط با Velero Pod است كه قبلاً مستقر شده است.
بياييد اولين پچ مخفي را با استفاده از دستور patch kubectl اعمال كنيم:

$kubectl patch secret/cloud-credentials -p “$(cat examples/01-velero-secret.patch.yaml)” –namespace velero
بايد خروجي زير را مشاهده كنيد:
secret/cloud-credentials patched

سرانجام ما Deployment را پچ مي كنيم. دستور زير را اجرا كنيد:
$kubectl patch deployment/velero -p “$(cat examples/02-velero-deployment.patch.yaml”) –namespace velero
در صورت موفقيت آميز بودن، خروجي زير را مشاهده خواهيد كرد:
deployment.apps/velero patched

بياييد تأييد كنيم كه آرايش پچ شده با استفاده از kubectl get در فضايvelero كار مي كند:
$kubectl get deployment/velero –namespace velero
بايد خروجي زير را مشاهده كنيد:
NAME READY UP-TO-DATE AVAILABLE AGE
velero 1/1 1 1 12s

در اين مرحله Velero در حال اجرا و كاملاً پيكربندي شده است ، و آماده تهيه نسخه پشتيبان و بازيابي موارد خوشه اي Kubernetes و واليوم هاي پايدار در vpsgol Spaces و Block Storage است.
در بخش بعدي ، ما يك آزمايش سريع انجام خواهيم داد تا اطمينان حاصل كنيم كه عملكرد نسخه پشتيبان و بازيابي همانطور كه انتظار مي رود ، كار مي كند.
مرحله ششم – تست تهيه نسخه پشتيبان و بازيابي فرآيند
اكنون كه Velero را با موفقيت نصب و پيكربندي كرده ايم ، مي توانيم با استفاده از واليوم و سرويس مداوم ، آزمايش Nginx Deployment را ايجاد كنيم. پس از اجراي Deployment ، از پشتيبان گيري استفاده مي كنيم و فرآيند را بازيابي مي كنيم تا اطمينان حاصل شود كه Velero پيكربندي شده و به درستي كار مي كند.
اطمينان حاصل كنيد كه هنوز در دايركتوري /tmp/velero-plugin-1.0.0 كار مي كنيد. دايركتوري examples  حاوي نمونه Nginx به نام nginx-shembull.yaml است.
اين فايل را با استفاده از ويرايشگر مورد نظر خود باز كنيد:
$nano examples/nginx-example.yaml
متن زير را بايد مشاهده كنيد:
Output
. . .

apiVersion: v1
kind: Namespace
metadata:
name: nginx-example
labels:
app: nginx


kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: nginx-logs
namespace: nginx-example
labels:
app: nginx
spec:
storageClassName: do-block-storage
accessModes:
– ReadWriteOnce
resources:
requests:
storage: 5Gi


apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
namespace: nginx-example
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
volumes:
– name: nginx-logs
persistentVolumeClaim:
claimName: nginx-logs
containers:
– image: nginx:stable
name: nginx
ports:
– containerPort: 80
volumeMounts:
– mountPath: “/var/log/nginx”
name: nginx-logs
readOnly: false


apiVersion: v1
kind: Service
metadata:
labels:
app: nginx
name: nginx-svc
namespace: nginx-example
spec:
ports:
– port: 80
targetPort: 80
selector:
app: nginx
type: LoadBalancer

در اين فايل فضاهايي براي موارد زير مشاهده مي كنيم:
⦁ يك نام فضاي Nginx به نام nginx-example
⦁ استقرار Nginx متشكل از يك نمونه كپي شده از تصوير كانتينر nginx:stable
⦁ ادعاي واليوم مداوم 5Gi (به نام log-nginx) با استفاده از do-block-storage در StorageClass
⦁ يك سرويس LoadBalancer كه پورت 80 را در معرض ديد قرار مي دهد
با استفاده از kubectl apply موارد را ايجاد كنيد:
$kubectl apply -f examples/nginx-example.yaml
بايد خروجي زير را مشاهده كنيد:
Output
namespace/nginx-example created
persistentvolumeclaim/nginx-logs created
deployment.apps/nginx-deploy created
service/nginx-svc created

بررسي كنيد كه استقرار موفق باشد:
$kubectl get deployments –namespace=nginx-example
بايد براي سرويس my-nginx هم CLUSTER-IP داخلي و هم EXTERNAL-IP را مشاهده كنيد:
Output
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-svc LoadBalancer 10.245.147.61 159.203.48.191 80:30232/TCP 3m1s

به EXTERNAL-IP توجه داشته باشيد و آن را به سمت استفاده از مرورگرتان هدايت كنيد.
هنگامي كه در دسترس قرار گرفت به 1 رسيد ، IP خارجي تعادل بار Nginx را با استفاده از kubectl دريافت كنيد:

شما بايد صفحه خوشامدگويي NGINX زير را ببينيد:

اين نشان مي دهد كه Nginx Deployme شما و خدمات به روز و در حال اجرا هستند.
قبل از شبيه سازي سناريوي فاجعه ما ، ابتدا ورود به دسترسي Nginx (كه در يك حجم مداوم متصل به Nginx Pod ذخيره شده) را بررسي كنيد:
$kubectl get pods –namespace nginx-example
Output
NAME READY STATUS RESTARTS AGE
nginx-deploy-694c85cdc8-vknsk 1/1 Running 0 4m14s

اكنون ، داخل كانتينر در حال اجرا Nginx وارد شويد تا به يك پوسته در داخل آن برسيد:
$kubectl exec -it nginx-deploy-694c85cdc8-vknsk –namespace nginx-example — /bin/bash

به محض ورود به كانتينر Nginx برويد ، ورودهاي دسترسي Nginx را cat كنيد:

# cat /var/log/nginx/access.log
بايد برخي از ورودي هاي Nginx را مشاهده كنيد:
Output
10.244.0.119 – – [03/Jan/2020:04:43:04 +0000] “GET / HTTP/1.1” 200 612 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0” “-”
10.244.0.119 – – [03/Jan/2020:04:43:04 +0000] “GET /favicon.ico HTTP/1.1” 404 153 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0” “-”

اين موارد را يادداشت كنيد (به ويژه زمانها) ، زيرا ما از آنها براي تأييد موفقيت در روش بازيابي استفاده خواهيم كرد. از pod خارج شويد:
$ exit
اكنون مي توانيم از روش پشتيبان گيري براي كپي كردن همه موارد nginx Kubernetes در Spaces استفاده كنيم و يك اسنپ شات از واليوم مداوم كه هنگام استقرار Nginx ايجاد كرديم را بگيريد.
$ velero backup create nginx-backup –selector app=nginx
برنامه –selector = nginx به سرور مجازي Velero دستور مي دهد تا فقط از موضوعات Kubernetes با انتخابگر ليبل app=nginx پشتيبان تهيه كند.
بايد خروجي زير را مشاهده كنيد:
Output
Backup request “nginx-backup” submitted successfully.
Run `velero backup describe nginx-backup` or `velero backup logs nginx-backup` for more details.

اجراي velero backup describe nginx-backup –details بايد خروجي زير را بعد از يك تأخير كوتاه ارائه دهد:
Output
Name: nginx-backup
Namespace: velero
Labels: velero.io/backup=nginx-backup
velero.io/pv=pvc-6b7f63d7-752b-4537-9bb0-003bed9129ca
velero.io/storage-location=default
Annotations:

Phase: Completed

Namespaces:
Included: *
Excluded:

Resources:
Included: *
Excluded:
Cluster-scoped: auto

Label selector: app=nginx

Storage Location: default

Snapshot PVs: auto

TTL: 720h0m0s

Hooks:

Backup Format Version: 1

Started: 2020-01-02 23:45:30 -0500 EST
Completed: 2020-01-02 23:45:34 -0500 EST

Expiration: 2020-02-01 23:45:30 -0500 EST

Resource List:
apps/v1/Deployment:
– nginx-example/nginx-deploy
apps/v1/ReplicaSet:
– nginx-example/nginx-deploy-694c85cdc8
v1/Endpoints:
– nginx-example/nginx-svc
v1/Namespace:
– nginx-example
v1/PersistentVolume:
– pvc-6b7f63d7-752b-4537-9bb0-003bed9129ca
v1/PersistentVolumeClaim:
– nginx-example/nginx-logs
v1/Pod:
– nginx-example/nginx-deploy-694c85cdc8-vknsk
v1/Service:
– nginx-example/nginx-svc

Persistent Volumes:
pvc-6b7f63d7-752b-4537-9bb0-003bed9129ca:
Snapshot ID: dfe866cc-2de3-11ea-9ec0-0a58ac14e075
Type: ext4
Availability Zone:
IOPS:

اين خروجي نشان مي دهد كه پشتيبان گيري nginx-backup با موفقيت انجام شد. ليست منابع هر يك از موضوعات Kubernetes را كه در نسخه پشتيبان تهيه شده است نشان مي دهد. بخش آخر نشان مي دهد كه از PersistentVolume نيز با استفاده از اسنپ شات فايل سيستم نسخه پشتيبان تهيه شده است.
براي تأييد از داخل كنترل پنل vpsgol Cloud ، به فضاي حاوي فايل هاي پشتيبان Kubernetes خود برويد.
شما بايد يك دايركتوري جديد با نام nginx-backup را ببينيد كه حاوي فايل هاي پشتيبان Velero است.
با استفاده از نوار ناوبري در سمت چپ ، به قسمت تصاوير و سپس اسنپ شات ها برويد. در اسنپ شات ها ، به Volume برويد. شما بايد Snapshot مربوط به PVC ذكر شده در خروجي فوق را مشاهده كنيد.
اكنون مي توانيم فرآيند بازيابي را آزمايش كنيم.
بياييد ابتدا نام فضاي nginx-example را حذف كنيم. با اين كار همه چيز در نام فضا، از جمله Load Balancer و واليوم مداوم حذف مي شود:
$kubectl delete namespace nginx-example
تأييد كنيد كه ديگر نمي توانيد به Nginx در انتهاي Load Balancer دسترسي پيدا كنيد ، و اين كه به كارگيري برنامه nginx-example ديگر در حال اجرا نيست:
$kubectl get deployments –namespace=nginx-example
Output
No resources found in nginx-example namespace.

اكنون مي توانيم دوباره با استفاده از مشتري velero ، فرآيند بازيابي را انجام دهيم:
$ velero restore create –from-backup nginx-backup
در اينجا ما از create  براي ايجاد مورد Velero Restore از موضوع nginx-backup استفاده مي كنيم.
بايد خروجي زير را مشاهده كنيد:
Output
$Restore request “nginx-backup-20200102235032” submitted successfully.
$Run `velero restore describe nginx-backup-20200102235032` or `velero restore logs nginx-backup-20200102235032` for more details.
وضعيت اجراي بازيابي شده را بررسي كنيد:
$kubectl get deployments –namespace=nginx-example
Output
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deploy 1/1 1 1 58s
ايجاد واليوم مداوم را بررسي كنيد
$kubectl get pvc –namespace=nginx-example
Output
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
nginx-logs Bound pvc-6b7f63d7-752b-4537-9bb0-003bed9129ca 5Gi RWO do-block-storage 75s

بازيابي همچنين LoadBalancer ايجاد كرد. گاهي اوقات سرويس با يك آدرس IP جديد ايجاد مي شود. بايد مجدداً آدرس EXTERNAL-IP را پيدا كنيد:

$kubectl get services –namespace nginx-example
Output
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-svc LoadBalancer 10.245.15.83 159.203.48.191 80:31217/TCP 97s
براي تأييد به روز رساني و اجراي Nginx ، يك بار ديگر به IP خارجي سرويس Nginx برويد.
در آخر ، ورودهاي مربوط به واليوم پايدار را بازبيني كنيد تا تأييد كنيد كه سابقه ورود پس از بازيابي ، حفظ شده است.
براي اين كار ، يك بار ديگر نام Pod را با استفاده از kubectl get دريافت كنيد:
$kubectl get pods –namespace nginx-example
Output
NAME READY STATUS RESTARTS AGE
nginx-deploy-694c85cdc8-vknsk 1/1 Running 0 2m20s

سپس به آن exec كنيد:
$kubectl exec -it nginx-deploy-694c85cdc8-vknsk –namespace nginx-example — /bin/bash
به محض ورود به كانتينر Nginx، ورودهاي دسترسي به Nginx را cat كنيد:
$cat /var/log/nginx/access.log
Output
10.244.0.119 – – [03/Jan/2020:04:43:04 +0000] “GET / HTTP/1.1” 200 612 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0” “-”
10.244.0.119 – – [03/Jan/2020:04:43:04 +0000] “GET /favicon.ico HTTP/1.1” 404 153 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0” “-”

شما بايد همان اقدامات دسترسي قبل از تهيه نسخه پشتيبان را ببينيد (بازه هاي زماني را يادداشت كنيد) كه تأييد ميكند كه بازيابي واليوم پايدار موفقيت آميز بوده است. توجه داشته باشيد پس از انجام بازيابي ، اگر از صفحه فرود Nginx بازديد كنيد ، ممكن است تلاش هاي بيشتري نياز باشد.
در اين مرحله ، ما با موفقيت از موضوعات Kubernetes خود در فضاهاي vpsgol و واليومهاي پايدار خود با استفاده از اسنپ شات هاي بلوك ذخيره سازي پشتيبان تهيه كرده ايم. ما يك سناريوي فاجعه را شبيه سازي كرديم و سرويس را به برنامه تست Nginx بازيابي كرديم.
نتيجه
در اين راهنما ابزار پشتيبان گيري Velero Kubernetes را روي يك خوشه مبتني بر vpsgol Kubernetes نصب و پيكربندي كرديم. ما اين ابزار را براي تهيه نسخه پشتيبان از موضوعات Kubernetes در vpsgol Spaces و پشتيبان گيري از واليوم هاي مداوم با استفاده از اسنپ شات هاي واليوم ذخيره سازي بلوك پيكربندي كرده ايم.

از Velero همچنين مي توان براي برنامه ريزي پشتيبان گيري منظم از خوشه Kubernetes براي بازيابي در برابر مشكلات استفاده كرد. براي اين كار مي توانيد از دستور velero schedule استفاده كنيد. Velero همچنين مي تواند براي انتقال منابع از يك خوشه به گروه ديگر استفاده شود.
براي كسب اطلاعات بيشتر در مورد vpsgol Spaces ، از مطالب رسمي Spaces كمك بگيريد. براي كسب اطلاعات بيشتر در مورد واليوم هاي ذخيره سازي بلوك ، با مستندات واليوم ذخيره سازي بلوك مشورت كنيد.
اين آموزش بر اساس README موجود در repo GitHub-plugin-plugin-digital-stackPointCloud


برچسب: ،
بازدید:

ادامه مطلب

نوشته شده: ۸ بهمن ۱۳۹۸ساعت: ۰۱:۲۶:۵۱ توسط:server موضوع:

نحوه نصب و استفاده از PostgreSQL در CentOS 7

مقدمه
سيستم هاي مديريت ديتابيس هاي منطقي يك مؤلفه اصلي بسياري از وب سايت ها و برنامه ها است. آنها روشي ساختاري براي ذخيره ، سازماندهي و دسترسي به اطلاعات را ارائه مي دهند.
PostgreSQL يا Postgres يك سيستم مديريت ديتابيس منطقي است كه اجراي زبان جستجوي SQL را فراهم مي كند. و يك انتخاب متداول براي بسياري از پروژه هاي كوچك و بزرگ است و اين مزيت را دارد كه مطابق با استانداردها مي باشد و داراي بسياري از ويژگي هاي پيشرفته مانند تعاملات مطمئن و همزماني بدون قفل خواندن است.
در اين راهنما؛ Postgres را بر روي سرور مجازي CentOS 7 نصب خواهيد كرد و برخي از روش هاي اصلي براي استفاده از آن را فرا مي گيريد.
پيش نيازها
براي دنبال كردن اين آموزش ، به موارد زير نياز داريد:
يك سرور مجازي CentOS 7 كه با پيروي از راهنماي راه اندازي سرور مجازي اوليه ما با CentOS 7 و مراحل توصيه شده بعدي براي سرورهاي جديد CentOS 7 ما ، شامل كاربر غير ريشه با امتيازات sudo و فايروال تنظيم شده با firewalld پيكربندي شده باشد.
براي راه اندازي firewalld ، بخش پيكربندي يك فايروال اساسي در آموزش ستاپ توصيه شده براي سرورهاي جديد CentOS 7 را دنبال كنيد.
اگر ديتابيس ها بسيار فعال باشند و داراي نشان زماني در سوابق داخلي باشند ، مي توانند به ويژه در برابر تغييرات زمان سيستم آسيب پذير باشند. براي جلوگيري از برخي رفتارهاي متناقض كه در اثر ساعتهاي خارج از همگام سازي ناشي مي شود ، حتماً با دنبال كردن بخش همگام سازي پروتكل زماني شبكه و محدوده هاي زماني پيكربندي در آموزش مراحل اضافي براي سرور مجازيCentOS 7 جديد، همگام سازي پروتكل زماني شبكه را (NTP) تنظيم كنيد. .
مرحله 1 – نصب PostgreSQL
Postgres را مي توان با استفاده از منابع پيش فرض CentOS نصب كرد. اما در مورد نوشتن اين آموزش ، نسخه اي كه در منبع پايه CentOS 7 موجود است منسوخ شده است. بنابراين ، در اين آموزش از منبع رسمي Postgres استفاده خواهد شد.

قبل از اقدام به ايجاد منبع جديد ، جستجوي بسته هاي postgresql را از منبع CentOS-Base حذف كنيد. در غير اين صورت ، وابستگي ها ممكن است نسبت به postgresql تهيه شده توسط منبع پايه برطرف شود.
فايل پيكربندي منبع را با استفاده از ويرايشگر متن مورد نظر خود باز كنيد. در اين آموزش از vim استفاده مي شود:
$sudo vi /etc/yum.repos.d/CentOS-Base.repo
بخش هاي [base] و [update] را پيدا كنيد ، با فشار دادن i وارد حالت insert شويد و خط exclud = postgresql * را در هر دو بخش وارد كنيد. در نتيجه ، فايل شما به شرح زير خواهد بود ، با خطوط جديد برجسته شده است:
/etc/yum.repos.d/CentOS-Base.repo

[base]
name=CentOS-$releasever – Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

exclude=postgresql*

#released updates
[updates]
name=CentOS-$releasever – Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
exclude=postgresql*

پس از اتمام ، ESC را فشار دهيد تا از حالت درج خارج شويد، سپس: wq و ENTER را براي ذخيره و خروج از فايل بزنيد. براي كسب اطلاعات بيشتر در مورد ويرايشگر متن vi و جانشين آن vim ، نصب و استفاده از ويرايشگر متن Vim را در آموزش Cloud Server ببينيد.
اكنون با استفاده از منبع رسمي PostgreSQL براي CentOS ، يك بسته تنظيمات منبع را نصب كنيد:

$sudo yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
هنگامي كه اعلان به شما داده شد ، نصب را با y تأييد كنيد.
منبع PostgreSQL شامل اطلاعات مربوط به همه نسخه هاي موجود PostgreSQL است. با استفاده از دستور زير مي توانيد تمام بسته ها و نسخه هاي موجود را مشاهده كنيد:
$yum list postgresql*
نسخه مورد نظر PostgreSQL را انتخاب و نصب كنيد. در اين راهنما از نسخه PostgreSQL 11 استفاده خواهيد كرد.
براي نصب سرور مجازي PostgreSQL از دستور زير استفاده كنيد:
$sudo yum install postgresql11-server
در طي مراحل نصب از شما خواسته مي شود تا كليد GPG را با اعلاني مانند موارد زير وارد كنيد:

Importing GPG key 0x442DF0F8:
Userid : “PostgreSQL RPM Building Project
Fingerprint: 68c9 e2b9 1a37 d136 fe74 d176 1f16 d2e1 442d f0f8
Package : pgdg-redhat-repo-42.0-5.noarch (installed)
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG
Is this ok [y/N]:

آن را با y تأييد كنيد تا نصب كامل شود.
اكنون كه نرم افزار نصب شده است ، شما براي تهيه خوشه ديتابيس جديد براي PostgreSQL مراحل ابتدايي را انجام خواهيد داد.
مرحله 2 – ايجاد يك خوشه ديتابيس جديد PostgreSQL
شما بايد قبل از استفاده از ديتابيس Postgres ، يك ديتابيس PostgreSQL  جديد ايجاد كنيد. يك خوشه ديتابيس مجموعه اي از بانكهاي داده است كه توسط يك سرور مجازي واحد مديريت مي شود. ايجاد يك خوشه ديتابيس شامل ايجاد دايركتوري هايي است كه در آن داده هاي ديتابيس قرار مي گيرد ، جداول كاتولوگ اشتراكي و بانكهاي اطلاعاتي template1 و postgres. را ايجاد ميكنند.
براي ايجاد يك ديتابيس جديد ، ديتابيس template1 لازم است. هر چيزي كه در آن ذخيره شده باشد ، هنگام ايجاد در يك ديتابيس جديد قرار مي گيرد. ديتابيس postgres يك ديتابيس پيش فرض است كه براي استفاده كاربران ، برنامه هاي كاربردي و برنامه هاي شخص ثالث طراحي شده است.

يك خوشه جديد براي ديتابيس PostgreSQL با initdb ايجاد كنيد:
$ sudo /usr/pgsql-11/bin/postgresql-11-setup initdb
خروجي زير را مشاهده خواهيد كرد:
Initializing database … OK

اكنون PostgreSQL را با استفاده از systemctl شروع و فعال كنيد:
$ sudo systemctl start postgresql-11
$ sudo systemctl enable postgresql-11
خروجي زير را مي دهد
Created symlink from /etc/systemd/system/multi-user.target.wants/postgresql-11.service to /usr/lib/systemd/system/postgresql-11.service.

اكنون كه PostgreSQL به روز شده و در حال اجرا است ، شما مي توانيد با استفاده از نقش ها ، ياد بگيريد كه چگونه Postgres كار مي كند و تفاوت آن با سيستم هاي مديريت ديتابيس مشابه شما كه ممكن است در گذشته استفاده كرده باشيد چيست.
مرحله 3 – استفاده از نقشها و بانكهاي اطلاعاتي PostgreSQL
به طور پيش فرض ، Postgres از مفهومي به نام نقش ها براي تأييد اعتبار و مجوز استفاده مي كند. اينها از بعضي جهات شبيه به حسابهاي معمولي يونيكس هستند اما Postgres بين كاربران و گروه ها فرق نمي گذارد و در عوض نقش انعطاف پذير تري را ترجيح مي دهد.
پس از نصب ، Postgres براي استفاده احراز هويت شناسايي تنظيم ميشود ، به اين معني كه نقش هاي Postgres با يك حساب كاربري سيستم Unix / Linux مرتبط مي شود. اگر نقشي در Postgres وجود داشته باشد ، يك نام كاربري يونيكس / لينوكس با همين نام قادر به ورود به عنوان آن نقش است.
روش نصب يك حساب كاربري به نام postgres ايجاد كرده است كه با نقش پيش فرض Postgres همراه است. براي استفاده از Postgres مي توانيد وارد آن حساب شويد.
چند روش براي استفاده از اين حساب براي دسترسي به Postgres وجود دارد.
انتقال به حساب Postgres
با تايپ كردن دستور زير به حساب Postgres در سرور مجازي خود سوييچ كنيد:
$ sudo -i -u postgres
اكنون مي توانيد با تايپ اين دستور فوراً به Postgres دسترسي پيدا كنيد:

$ psql
با اين كار شما وارد اعلان PostgreSQL مي شويد و از اينجا مي توانيد بلافاصله با سيستم مديريت ديتابيس ارتباط برقرار كنيد.
با تايپ كردن اين دستور از اعلان PostgreSQL خارج شويد:
Postgres=# q
اين شما را به خط فرمان سريع postgres Linux بازميگرداند. اكنون با دستور زير به حساب sudo اصلي خود برگرديد:
$ exit
دسترسي به يك Postgres سريع بدون تعويض حساب
همچنين مي توانيد دستور مورد نظر خود را با حساب postgres به طور مستقيم با sudo اجرا كنيد.
به عنوان مثال ، در نمونه آخر ، به شما دستور داده شد كه ابتدا با سوييچ كردن به كاربر Postgres و سپس اجراي psql براي باز كردن اعلان Postgres ، سريعاً بهPostgres برسيد. شما مي توانيد اين كار را در يك مرحله با اجراي فرمان واحد psql به عنوان كاربر postgres با sudo انجام دهيد ، مانند اين:
$ sudo -u postgres psql
با اين كار بدون پوسته bash مستقيماً وارد Postgres خواهيد شد.
دوباره مي توانيد با تايپ كردن اين دستور از بخش Postgres تعاملي خارج شويد:
Postgres=# q
در اين مرحله، از حساب Postgres براي رسيدن به اعلان psql استفاده كرديد. اما بسياري از موارد استفاده بيشتر به يك نقش Postgres نياز دارند. براي يادگيري نحوه پيكربندي نقشهاي جديد به خواندن متن ادامه دهيد.
مرحله 4 – ايجاد نقش جديد
در حال حاضر ، شما فقط نقش postgres ها را در ديتابيس پيكربندي كرده ايد. مي توانيد با استفاده از دستور Createrole نقش هاي جديدي را از خط فرمان ايجاد كنيد. فلگ –interactive نام نقش جديد را به شما اعلان ميكند و همچنين سؤال ميكند كه آيا مجوزهاي فوق كاربري بايد داته باشد يا خير.
اگر به عنوان حساب postgres وارد شويد ، مي توانيد با تايپ كردن اين دستور كاربر جديدي ايجاد كنيد:
postgres@server:$ createuser –interactive
در عوض ، اگر ترجيح مي دهيد بدون تغيير حساب عادي خود از sudo براي هر دستور استفاده كنيد ، تايپ كنيد:
$ sudo -u postgres createuser –interactive
اين متن با انتخاب هاي مختلفي شما را باخبر مي كند و بر اساس پاسخ هاي شما ، دستورات درست Postgres را براي ايجاد يك كاربر براي مشخصات شما اجرا مي كند. براي اين آموزش ، يك كاربر sammy ايجاد كنيد و به آن امتيازات فوق كاربر بدهيد:
Enter name of role to add: sammy
Shall the new role be a superuser? (y/n) y

با عبور برخي از فلگ هاي اضافي مي توانيد كنترل بيشتري به دست آوريد. گزينه ها را با مراجعه به صفحه man بررسي كنيد:
$ man createuser
نصب شما در Postgres اكنون كاربر جديدي دارد ، اما شما هنوز هيچ ديتابيسي اضافه نكرده ايد. در بخش بعدي اين روند توضيح داده شده است.
مرحله 5 – ايجاد يك ديتابيس جديد
فرض ديگري كه سيستم تأييد اعتبار Postgres بطور پيش فرض انجام مي دهد اين است كه براي هر نقشي كه براي ورود به سيستم استفاده مي شود ، آن نقش يك ديتابيس با همان نام دارد كه مي تواند به آن دسترسي داشته باشد.
اين بدان معني است كه ، اگر كاربري كه در آخرين بخش ايجاد كرده ايد ، sammy خوانده شود ، اين نقش سعي خواهد كرد به يك ديتابيس وصل شود كه به طور پيش فرض نيز sammy ناميده مي شود. مي توانيد با دستور createdb  ديتابيس مناسب ايجاد كنيد.
اگر به عنوان حساب postgres وارد ميشويد، مطمئناً شما مي توانيد چيزي شبيه اين تايپ خواهيد كرد:
postgres@server:$ createdb sammy
در عوض ، اگر ترجيح مي دهيد بدون تغيير از حساب عادي خود ، از sudo براي هر فرمان استفاده كنيد ، تايپ كنيد:
$ sudo -u postgres createdb sammy
اين انعطاف پذيري در صورت نياز چندين مسير براي ايجاد ديتابيس جديد فراهم مي كند.
اكنون كه يك ديتابيس جديد ايجاد كرده ايد ، با نقش جديد خود وارد آن خواهيد شد.

مرحله ششم – باز كردن اعلان Postgres با نقش جديد
براي ورود به تأييد هويت مبتني بر ident ، به يك كاربر لينوكس با همان نام و نقش ديتابيس Postgres خود نياز داريد.
اگر يك كاربر سازگار با لينوكس در دسترس نداريد ، مي توانيد يكي از آنها را با دستور adduser ايجاد كنيد. شما بايد اين كار را از حساب غير ريشه خود با امتيازات sudo انجام دهيد (به اين معني كه به عنوان كاربر postgres وارد نشده ايد):
$ sudo adduser sammy
پس از در دسترس بودن اين حساب جديد ، مي توانيد با تايپ كردن به ديتابيس سوييچ كنيد و وصل شويد:
$ sudo -i -u sammy
$ psql
يا مي توانيد اين كار را بصورت درون خطي انجام دهيد:
$ sudo -u sammy psql
اين دستور شما را به طور خودكار وارد مي كند.
اگر مي خواهيد كاربر شما به يك ديتابيس ديگر متصل شود ، مي توانيد با مشخص كردن ديتابيس مانند دستور زير اين كار را انجام دهيد:
$ psql -d postgres
پس از ورود به سيستم ، مي توانيد اطلاعات اتصال فعلي خود را با تايپ كردن دستور زير بررسي كنيد:
Sammy=# conninfo
خروجي زير را نشان خواهد داد:
You are connected to database “sammy” as user “sammy” via socket in “/var/run/postgresql” at port “5432”.

اين امر در صورت اتصال به ديتابيس هاي غير پيش فرض يا با كاربران غير پيش فرض مفيد است.
با اتصال به ديتابيس خود ، اكنون مي توانيد ايجاد و حذف جداول را امتحان كنيد.
مرحله 7 – ايجاد و حذف جداول
اكنون كه مي دانيد چگونه به سيستم ديتابيس PostgreSQL وصل شويد ، مي توانيد برخي از وظايف اساسي مديريت Postgres را ياد بگيريد.
ابتدا يك جدول براي ذخيره برخي داده ها ايجاد كنيد. به عنوان نمونه ، جدولي را تهيه خواهيد كرد كه برخي از تجهيزات زمين بازي را شرح مي دهد.
تركيب اصلي اين دستور به شرح زير است:
CREATE TABLE table_name (
column_name1 col_type (field_length) column_constraints,
column_name2 col_type (field_length),
column_name3 col_type (field_length)
);
اين دستورات به جدول اسمي مي دهند و سپس ستون ها و همچنين نوع ستون و حداكثر طول داده هاي ميدان را مشخص مي كنند. همچنين مي توانيد محدوديت هاي جدول را براي هر ستون به صورت اختياري اضافه كنيد.
مي توانيد اطلاعات بيشتري در مورد نحوه ايجاد ، حذف و مديريت جداول در PostgreSQL در يك آموزش Cloud Server دريافت كنيد.
براي اهداف توضيحي ، يك جدول ساده مانند اين ايجاد كنيد:
CREATE TABLE playground (
equip_id serial PRIMARY KEY,
type varchar (50) NOT NULL,
color varchar (25) NOT NULL,
location varchar(25) check (location in (‘north’, ‘south’, ‘west’, ‘east’, ‘northeast’, ‘southeast’, ‘southwest’, ‘northwest’)),
install_date date
);

اين دستورات يك جدول ايجاد مي كند كه تجهيزات زمين بازي را ذخيره مي كند. اين كار با يك شناسه تجهيزات شروع مي شود كه از نوع serial  است. اين نوع داده يك عدد صحيح است كه به طور خودكار رو به افزايش است. شما همچنين به اين ستون محدوديت primary keyرا داده ايد ، به اين معني كه مقادير بايد منحصر به فرد باشند و خنثي نباشند.
براي دو ستون (equip_id و install_date) ، دستورات طول فيلد را مشخص نمي كنند. دليل اين امر اين است كه برخي از انواع ستونها به طول مشخصي نياز ندارند زيرا طول دلالت بر نوع است.
دو دستور بعدي به ترتيب ستونهايي را براي نوع و رنگ تجهيزات ايجاد مي كنند كه هر يك از آنها نمي تواند خالي باشد. دستور بعد از اينها يك ستون مكان و يك محدوديت ايجاد مي كند كه نياز دارد اين مقدار يكي از هشت مقدار ممكن باشد. دستور آخر يك ستون تاريخ ايجاد مي كند كه تاريخ نصب تجهيزات را ثبت مي كند.
مي توانيد جدول جديد خود را با تايپ كردن دستور زير مشاهده كنيد:
Sammy=# d
خروجي زير را نشان مي دهد:
List of relations
Schema | Name | Type | Owner
——–+————————-+———-+——-
public | playground | table | sammy
public | playground_equip_id_seq | sequence | sammy
(2 rows)

جدول زمين بازي شما اينجاست ، اما چيزي به نام playground_equip_id_seq نيز وجود دارد كه از نوع sequence است. اين نمايشي از نوع serial  است كه شما به ستون equip_id خود داده ايد. اين شماره بعدي را در ترتيب دنبال مي كند و به طور خودكار براي ستون هاي اين نوع ايجاد مي شود.
اگر مي خواهيد فقط جدول بدون ترتيب را ببينيد ، مي توانيد تايپ كنيد:
Sammy=# dt
به خروجي زير منجر ميشود:
List of relations
Schema | Name | Type | Owner
——–+————+——-+——-
public | playground | table | sammy
(1 row)

در اين مرحله يك جدول نمونه ايجاد كرده ايد. در مرحله بعد ، سعي در اضافه كردن ، درخواست و حذف مطالب در آن جدول خواهيد كرد.
مرحله 8 – اضافه كردن ، جستجو و حذف داده ها در يك جدول
اكنون كه جدول داريد ، مي توانيد برخي از داده ها را در آن وارد كنيد.
به عنوان نمونه ، با فراخواني جدول موردنظر براي افزودن ، نامگذاري ستونها ، و سپس تهيه داده براي هر ستون ، يك slide و swing را اضافه كنيد:
Sammy=# INSERT INTO playground (type, color, location, install_date) VALUES (‘slide’, ‘blue’, ‘south’, ‘2017-04-28’);
Sammy=# INSERT INTO playground (type, color, location, install_date) VALUES (‘swing’, ‘yellow’, ‘northwest’, ‘2018-08-16’);
شما بايد هنگام وارد كردن داده ها مراقب باشيد تا از معدود مشكلات معمول جلوگيري شود. براي يك ، نام ستون ها را در علامت نق قول نگذاريد ، اما مقادير ستون كه وارد مي كنيد به نقل قول نياز دارند.
نكته ديگري كه بايد در نظر داشته باشيد اين است كه براي ستون equip_id مقداري وارد نمي كنيد. به اين دليل است كه هر زمان كه يك رديف جديد در جدول ايجاد شود ، به طور خودكار شكل ميگيرد.
با تايپ كردن دستور زير اطلاعاتي كه اضافه كرده ايد بازيابي كنيد:
Sammy=# SELECT * FROM playground;
خروجي زير را مشاهده خواهيد كرد:

equip_id | type | color | location | install_date
———-+——-+——–+———–+————–
1 | slide | blue | south | 2017-04-28
2 | swing | yellow | northwest | 2018-08-16
(2 rows)

در اينجا ، مي بينيد كه equip_id شما با موفقيت پر شده است و تمام داده هاي ديگر شما به درستي سازماندهي شده اند.
اگر slide روي زمين بازي خراب شد و مجبور شديد آن را حذف كنيد ، مي توانيد با تايپ كردن دستور زير سطر را از جدول خود حذف نماييد:
Sammy=# DELETE FROM playground WHERE type = ‘slide’;
جدول را دوباره فراخواني كنيد:
Sammy=# SELECT * FROM playground;
موارد زير را مشاهده خواهيد كرد:
equip_id | type | color | location | install_date
———-+——-+——–+———–+————–
2 | swing | yellow | northwest | 2018-08-16
(1 row)

توجه كنيد كه اسلايد شما ديگر جزئي از جدول نيست.
اكنون كه ورودي هاي خود را در جدول خود اضافه كرده ايد و حذف كرده ايد ، مي توانيد ستون ها را اضافه و حذف كنيد.

مرحله 9 – اضافه كردن و حذف ستون ها از يك جدول
پس از ايجاد جدول ، مي توانيد آن را تغيير دهيد تا ستون ها اضافه يا حذف شوند. براي نمايش آخرين بازديد نگهداري براي هر قطعه تجهيزات ، يك ستون اضافه كنيد:
Sammy=# ALTER TABLE playground ADD last_maint date;
اگر اطلاعات جدول خود را دوباره مشاهده كنيد ، مي بينيد كه ستون جديد اضافه شده است (اما هيچ داده اي وارد نشده است(:
Sammy=# SELECT * FROM playground;
خروجي زير را مشاهده خواهيد كرد:
equip_id | type | color | location | install_date | last_maint
———-+——-+——–+———–+————–+————
2 | swing | yellow | northwest | 2018-08-16 |
(1 row)

حذف ستون به همين سادگي است. اگر متوجه شديد كه خدمه كاري شما از يك ابزار جداگانه براي پيگيري تاريخچه نگهداري استفاده مي كنند ، مي توانيد ستون را با تايپ كردن اين دستور حذف كنيد:
Sammy=# ALTER TABLE playground DROP last_maint;
اين ستون last_maint و مقادير موجود در آن را حذف مي كند ، اما تمام داده هاي ديگر را دست نخورده مي گذارد.
با افزودن و حذف ستونها، مي توانيد داده هاي موجود را در مرحله آخر به روز كنيد.
مرحله 10 – به روزرساني داده ها در يك جدول
تاكنون ياد گرفته ايد كه چگونه مي توانيد سوابق را به يك جدول اضافه كنيد و چگونه آنها را حذف كنيد ، اما اين آموزش هنوز نحوه تغيير ورودي هاي موجود را پوشش نداده است.
مي توانيد مقادير ورودي موجود را با فراخواني ركورد مورد نظر خود به روز كنيد و ستون را روي مقدار مورد نظر خود تنظيم كنيد. مي توانيد از سوابق swing  (با هر swing در جدول شما منطبق ميشود) استفاده كنيد و رنگ آن را به رنگ قرمز تغيير دهيد:
Sammy=# UPDATE playground SET color = ‘red’ WHERE type = ‘swing’;
با فراخواني داده ها دوباره مي توانيد تأييد كنيد كه اين عمليات با موفقيت انجام شد:
Sammy=# SELECT * FROM playground;
خروجي زير را مشاهده خواهيد كرد:
equip_id | type | color | location | install_date
———-+——-+——-+———–+————–
2 | swing | red | northwest | 2010-08-16
(1 row)

همانطور كه مشاهده مي كنيد ، اكنون اسلايدها به عنوان قرمز ثبت شده است.
نتيجه
اكنون تنظيم PostgreSQL در سرور مجازي CentOS 7 خود را انجام داده ايد. با اين حال ، هنوز چيزهاي بيشتري براي يادگيري Postgres وجود دارد. در اينجا چند راهنماي ديگر كه نحوه استفاده از Postgres را پوشش مي دهند آورده شده است:
مقايسه سيستم هاي مديريت ديتابيس منطقي
با نحوه ايجاد و مديريت جداول با Postgres آشنا شويد
در مديريت نقش ها و مجوزها حرفه اي تر شويد
فراخواني مهارت در Postgres با Selec


برچسب: ،
بازدید:

ادامه مطلب

نوشته شده: ۸ بهمن ۱۳۹۸ساعت: ۰۱:۲۶:۲۶ توسط:server موضوع:

چگونه مي توان پلتفرم Eclipse Theia Cloud IDE را روي اوبونتو 18.4 تنظيم كرد

مقدمه
با حركت ابزارهاي گسترش دهنده به سمت cloud ، پذيرش پلتفرم cloud IDE (محيط پيشرفت در هم تنيده) در حال رشد است. Cloud IDE از هر نوع دستگاه مدرن از طريق مرورگرهاي وب قابل دسترسي است و براي سناريوهاي همكاري در زمان واقعي مزاياي بسياري را ارائه مي دهند. كار در يك Cloud IDE ، يك محيط توسعه و آزمايش يكپارچه را براي شما و تيم شما ايجاد مي كند ، در عين حال ناسازگاري هاي پلتفرم را به حداقل مي رساند. چون از طريق مرورگرهاي وب قابل دسترسي است ، Cloud IDE ها از هر نوع دستگاه مدرن در دسترس هستند.
Eclipse Theia يك Cloud IDE قابل توسعه است كه بر روي يك سرور مجازي از راه دور و از يك مرورگر وب قابل دسترسي است. از لحاظ بصري ، طراحي شده است كه به طور مشابه با Microsoft Visual Studio Code ديده شود و با آن كار شود ، به اين معني كه از بسياري از زبان هاي برنامه نويسي پشتيباني مي كند ، داراي يك طرح انعطاف پذير و يك ترمينال يكپارچه است. آنچه Eclipse Theia را از ديگر نرم افزارهاي cloud IDE جدا مي كند قابليت توسعه آن است. مي توان آن را با استفاده از افزونه هاي سفارشي اصلاح كرد ، كه به شما امكان مي دهد يك Cloud IDE متناسب با نيازهاي خود تهيه كنيد.
در اين آموزش ،Eclipse Theia را با استفاده از Docker Compose ، يك ابزار اركستر، به سرور مجازي Ubuntu 18.04 خود منتقل خواهيد كرد. شما آن را در دامنه خود با استفاده از nginx-proxy ، يك سيستم خودكار براي Docker قرار مي دهيد كه فرايند پيكربندي Nginx را ساده تر مي كند تا به عنوان يك پروكسي معكوس براي يك container سرويس دهد. شما با استفاده از يك گواهي نامه Let Encrypt TLS رايگان ، كه با استفاده از افزونه تخصصي آن تهيه مي كنيد ، آن را ايمن خواهيد كرد. در پايان ، شما بايد Eclipse Theia را روي سرور مجازي Ubuntu 18.04 خود از طريق HTTPS در دسترس داشته باشيد و از كاربر بخواهيد وارد شود.
پيش نيازها
⦁ يك سرور مجازي Ubuntu 18.04 با امتيازات اصلي و يك حساب ثانويه و غير ريشه. مي توانيد با دنبال كردن راهنماي تنظيم اوليه سرور مجازي ما براي Ubuntu 18.04 ، اين تنظيمات را انجام دهيد. براي اين آموزش كاربر غير ريشه sammy است.
⦁ Docker نصب شده روي سرور مجازي شما. مرحله 1 و مرحله 2 نحوه نصب Docker را در اوبونتو 18.04 دنبال كنيد. براي آشنايي با Docker ، به اكوسيستم Docker: مقدمه اي بر مؤلفه هاي مشترك مراجعه كنيد.
⦁ Docker compose روي سرور مجازي شما نصب است. مرحله 1 نحوه نصب Docker Compose را در اوبونتو 18.04 دنبال كنيد.
⦁ نام دامنه كاملاً ثبت شده. در اين آموزش كلا از theia.your_domain استفاده مي شود. مي توانيد نام دامنه را در Namecheap خريداري كنيد ، يكي از آنها را به صورت رايگان در Freenom دريافت كنيد ، يا از ثبت دامنه مورد نظر خود استفاده كنيد.
⦁ يك ثبت A DNS با theia.your_domain كه به آدرس IP عمومي سرور مجازي شما اشاره ميكند. براي جزئيات بيشتر در مورد چگونگي اضافه كردن آنها مي توانيد اين معرفي را در vpsgol DNS دنبال كنيد.
مرحله 1 – استفاده از پروكسي nginx با Let’s Encrypt
در اين بخش nginx-proxy و افزونه Let’s Encrypt را با استفاده از Docker Compose به كار ميگيريد. اين امر امكان تهيه و نوسازي مجوز خودكار TLS را فراهم مي كند ، به طوري كه هنگام استقرار Eclipse Theia از طريق HTTPS در دامنه شما قابل دسترسي خواهد بود.
براي اهداف اين آموزش ، تمام فايل ها را تحت ~ / eclipse-theia ذخيره مي كنيد. با اجراي دستور زير دايركتوري ايجاد كنيد:
⦁ $ mkdir ~/eclipse-theia
به آن مراجعه كنيد:
⦁ $ cd ~/eclipse-theia
پيكربندي Docker Compose را براي nginx-proxy در فايلي به نام nginx-proxy-compose.yaml ذخيره خواهيد كرد. آن را با استفاده از ويرايشگر متن خود ايجاد كنيد:
⦁ $nano nginx-proxy-compose.yaml
خطوط زير را اضافه كنيد:
~/eclipse-theia/nginx-proxy-compose.yaml
version: ‘2’

services:
nginx-proxy:
restart: always
image: jwilder/nginx-proxy
ports:
– “80:80”
– “443:443”
volumes:
– “/etc/nginx/htpasswd:/etc/nginx/htpasswd”
– “/etc/nginx/vhost.d”
– “/usr/share/nginx/html”
– “/var/run/docker.sock:/tmp/docker.sock:ro”
– “/etc/nginx/certs”

letsencrypt-nginx-proxy-companion:
restart: always
image: jrcs/letsencrypt-nginx-proxy-companion
volumes:
– “/var/run/docker.sock:/var/run/docker.sock:ro”
volumes_from:
– “nginx-proxy”

در اينجا شما دو سرويس را تعريف مي كنيد كه Docker Compose اجرا خواهد كرد ، nginx-proxy و همراه آن Let’s Encrypt. براي پروكسي ، شما jwilder / nginx-proxy را به عنوان تصوير مشخص ميكنيد، پورت هاي HTTP و HTTPS را نقشه برداري مي كنيد ، و حجم هايي را تعريف مي كنيد كه در زمان اجرا در دسترس شما خواهد بود.
حجم ها دايركتوري هايي در سرور مجازي شما هستند كه سرويس تعريف شده به آنها دسترسي كامل خواهد داشت ، كه بعداً براي تنظيم تأييد اعتبار كاربر از آنها استفاده خواهيد كرد. براي دستيابي به اين هدف ، از جلد اول ليست استفاده مي كنيد ، كه دايركتوري محلي / etc / nginx / htpasswd را به همان قسمت موجود در داخل آن نگاشت مي كشد. در آن پوشه ، nginx-proxy انتظار دارد فايلي را به نام دامنه هدف پيدا كند ، كه حاوي اطلاعات ورود به سيستم براي احراز هويت كاربر در قالب htpasswd (نام كاربري: hashed_password) است.
براي افزودن ، شما تصوير Docker را نامگذاري مي كنيد و با تعيين يك حجم امكان دسترسي به سوكت Docker را مي دهيد. سپس ، شما مشخص مي كنيد كه اين افزونه بايد دسترسي به حجمهاي تعريف شده براي nginx-proxy را ادامه دهد. هر دو سرويس
تنظيمات راه اندازي مجدد دارند ، كه روي ALWAYS تنظيم ميشود و به Docker دستور مي دهد كانتينر را در صورت خرابي يا ريبوت سيستم مجدداً راه اندازي كند.
فايل را ذخيره كنيد و ببنديد.
پيكربندي را با اجراي دستور انجام دهيد:
⦁ $ docker-compose -f nginx-proxy-compose.yaml up -d
در اينجا نام فايل nginx-proxy-compose.yaml را در پارامتر -f دستور docker-compose مي گذاريد ، كه فايل را براي اجرا مشخص مي كند. سپس ، شما فعل UP را مي گذرانيد كه به آن دستور مي دهد كانتينرها را اجرا كند. پرچم -d حالت جداشده را فعال مي سازد ، به اين معني كه Docker Compose كانتينرها را در پس زمينه اجرا مي كند.
خروجي نهايي به شرح زير خواهد بود:
Output
Creating network “eclipse-theia_default” with the default driver
Pulling nginx-proxy (jwilder/nginx-proxy:)…
latest: Pulling from jwilder/nginx-proxy
8d691f585fa8: Pull complete
5b07f4e08ad0: Pull complete

Digest: sha256:dfc0666b9747a6fc851f5fb9b03e65e957b34c95d9635b4b5d1d6b01104bde28
Status: Downloaded newer image for jwilder/nginx-proxy:latest
Pulling letsencrypt-nginx-proxy-companion (jrcs/letsencrypt-nginx-proxy-companion:)…
latest: Pulling from jrcs/letsencrypt-nginx-proxy-companion
89d9c30c1d48: Pull complete
668840c175f8: Pull complete

Digest: sha256:a8d369d84079a923fdec8ce2f85827917a15022b0dae9be73e6a0db03be95b5a
Status: Downloaded newer image for jrcs/letsencrypt-nginx-proxy-companion:latest
Creating eclipse-theia_nginx-proxy_1 … done
Creating eclipse-theia_letsencrypt-nginx-proxy-companion_1 … done

شما nginx-proxy و همراهش Let’s Encrypt را با استفاده از Docker Compose به كار گرفته ايد. اكنون مي توانيد Eclipse Theia را در دامنه خود تنظيم كرده و آن را ايمن كنيد.
مرحله 2 – به كارگيري Eclipse Theia دوكر شده
در اين بخش ، فايلي را ايجاد خواهيد كرد كه شامل هر تركيب ورود به سيستم مجاز است كه كاربر بايد آن را وارد كند. سپس Eclipse Theia را با استفاده از Docker Compose به سرور مجازي خود منتقل مي كنيد و با استفاده از nginx-proxy آن را در دامنه امن خود قرار مي دهيد.
همانطور كه در مرحله قبل توضيح داده شد ، nginx-proxy انتظار دارد كه تركيب هاي ورود به سيستم در فايلي به نام دامنه در معرض ، با فرمت htpasswd قرار بگيرند و در دايركتوري / etc / nginx / htpasswd در كانتينر ذخيره شوند. همانطور كه در پيكربندي nginx-proxy مشخص كرده ايم ، دايركتوري محلي كه به دايركتوري مجازي نگاشت مي كند ، نيازي به يكسان بودن ندارد.
براي ايجاد تركيبات ورود ، ابتدا با اجراي دستور زير بايد htpasswd را نصب كنيد:
⦁ $ sudo apt install apache2-utils

پكيج apache2-utils حاوي برنامه htpasswd است.
دايركتوري / etc / nginx / htpasswd را ايجاد كنيد:
⦁ $ sudo mkdir -p /etc/nginx/htpasswd
فايلي ايجاد كنيد كه ورود به سيستم را براي دامنه شما ذخيره كند:

⦁ $ sudo touch /etc/nginx/htpasswd/theia.your_domain

به ياد داشته باشيد theia.your_domain را با دامنه Eclipse Theia خود جايگزين كنيد.
براي افزودن نام كاربري و رمز ورود ، دستور زير را اجرا كنيد:
⦁ $ sudo htpasswd /etc/nginx/htpasswd/theia.your_domain username
USERNAME را با نام كاربري كه مي خواهيد اضافه كنيد جايگزين كنيد. از شما دوبار رمز عبور خواسته مي شود. پس از ارائه آن ، htpasswd نام كاربري و جفت رمز عبور را در انتهاي فايل اضافه مي كند. مي توانيد اين دستور را به هر تعداد ورود به سيستم كه ميخواهيد تكرار كنيد.
اكنون ، پيكربندي را براي استقرار Eclipse Theia ايجاد خواهيد كرد. شما آن را در فايلي به نام eclipse-theia-compose.yaml ذخيره خواهيد كرد. آن را با استفاده از ويرايشگر متن خود ايجاد كنيد:
⦁ $ nano eclipse-theia-compose.yaml
خطوط زير را اضافه كنيد:
~/eclipse-theia/eclipse-theia-compose.yaml
version: ‘2.2’

services:
eclipse-theia:
restart: always
image: theiaide/theia:next
init: true
environment:
– VIRTUAL_HOST=theia.your_domain
– LETSENCRYPT_HOST=theia.your_domain

در اين پيكربندي ، شما يك سرويس واحد به نام eclipse-theia با ريستارت براي ALWAYS و theiaide/theia:next به عنوان تصوير كانتينر تعريف مي كنيد: شما همچنين مي توانيد init را روي true تنظيم كنيد تا به Docker دستور دهيد هنگام اجراي Eclipse Theia در داخل كانتينر ، از init به عنوان مدير اصلي فرآيند استفاده كند.
سپس دو متغير محيط را در بخش environment مشخص مي كنيد: VIRTUAL_HOST و LETSENCRYPT_HOST. اولين مورد به پروكسي nginx منتقل مي شود و به آن مي گويد كانتينر چه دامنه اي را بايد در معرض ديد قرار دهيد ، در حالي كه دومي توسط افزونه Let’s Encrypt آن استفاده مي شود و مشخص مي كند كه براي كدام دامنه درخواست گواهينامه TLS شود. مگر اينكه يك wildcard را به عنوان مقدار VIRTUAL_HOST تعيين كنيد ، اين دو مقدار بايد يكسان باشند.
به ياد داشته باشيد theia.your_domain را با دامنه مورد نظر خود جايگزين كنيد ، سپس فايل را ذخيره كنيد و ببنديد. اكنون با اجراي دستور زير Eclipse Theia را اجرا كنيد:
⦁ $ docker-compose -f eclipse-theia-compose.yaml up -d
خروجي نهايي مشابه زير به نظر مي رسد:
Output

Pulling eclipse-theia (theiaide/theia:next)…
next: Pulling from theiaide/theia
63bc94deeb28: Pull complete
100db3e2539d: Pull complete

Digest: sha256:c36dff04e250f1ac52d13f6d6e15ab3e9b8cad9ad68aba0208312e0788ecb109
Status: Downloaded newer image for theiaide/theia:next
Creating eclipse-theia_eclipse-theia_1 … done

سپس در مرورگر خود به دامنه مورد استفاده براي Eclipse Theia برويد. مرورگر شما فوريتي را به شما نشان مي دهد كه از شما خواسته مي شود وارد شويد. پس از ارائه اطلاعات صحيح ، شما وارد Eclipse Theia مي شويد و بلافاصله رابط كاربري گرافيكي آن را مشاهده مي كنيد. در نوار آدرس
يك پدلاك را مشاهده خواهيد كرد كه نشان مي دهد اتصال امن است. اگر اين را بلافاصله مشاهده نكرديد ، چند دقيقه صبر كنيد تا گواهينامه هاي TLS ارائه شود ، سپس صفحه را مجدد بارگيري كنيد.

اكنون كه مي توانيد به راحتي به cloud IDE خود دسترسي داشته باشيد ، در مرحله بعد شروع به استفاده از ويرايشگر خواهيد كرد.

مرحله 3 – استفاده از رابط Eclipse Theia
در اين بخش به بررسي برخي از ويژگي هاي رابط Eclipse Theia مي پردازيد.
در سمت چپ IDE ، يك رديف عمودي از چهار دكمه وجود دارد كه متداول ترين ويژگي هاي مورد استفاده را در يك صفحه جانبي باز مي كند.
اين نوار قابل تنظيم است بنابراين مي توانيد اين نماها اين نوار قابل سفارشي


برچسب: ،
بازدید:

ادامه مطلب

نوشته شده: ۸ بهمن ۱۳۹۸ساعت: ۰۱:۲۵:۴۹ توسط:server موضوع:

چگونه پيكربندي SSH Daemon خود را بر روي يك VPS لينوكس تنظيم كنيد

مقدمه
SSH راه اصلي براي اتصال به سرورهاي راه دور لينوكس و يونيكس مانند از طريق خط فرمان است. كه يك اتصال مطمئن فراهم مي كند كه مي توانيد از آن براي اجراي دستورات ، تعامل با سيستم و حتي تونل زدن از ميان ترافيك نامربوط استفاده كنيد.
بيشتر كاربران از اصول اوليه چگونگي شروع و اتصال به يك سرور از راه دور با يك فرمان مانند زير آگاه هستند:
ssh username@remote_server

با اين حال ، گزينه هاي بيشتري در رابطه با پيكربندي Demon SSH وجود دارد كه مي تواند براي افزايش امنيت ، مديريت اتصالات كاربر و غيره مفيد باشد. ما در مورد برخي از گزينه هاي موجود در اختيار شما بحث خواهيم كرد تا كنترل دقيق تري روي دسترسي SSH داشته باشيد. .
ما اين مفاهيم را به طور نمونه از Ubuntu 12.04 VPS استفاده خواهيم كرد ، اما هر توزيع مدرن لينوكس بايد به روشي مشابه عمل كند.
كاوش در فايل پيكربندي SSHD
منبع اصلي پيكربندي مربوط به Demon SSH در فايل / etc / ssh / sshd_config است. توجه داشته باشيد كه اين با فايل ssh_config متفاوت است ، كه پيش فرض سمت مشتري را مشخص مي كند.
اكنون فايل را با امتيازات ادمين باز كنيد:
sudo nano /etc/ssh/sshd_config

شما يك فايل با ويژگي هاي كاملاً متفاوت را مشاهده خواهيد كرد و خوشبختانه (بسته به توزيع خود) نظرهاي زيادي را نيز مشاهده ميكنيد. در حالي كه اكثر توزيع ها كار نسبتاً خوبي براي ايجاد پيش فرض هاي عاقلانه انجام مي دهند ، همچنان جاي بهبود و سفارشي سازي وجود دارد.
بياييد به برخي از گزينه هايي كه قبلاً در فايل ما در اوبونتو 12.04 تنظيم شده اند بپردازيم:
پورت ها و پروتكل ها
پورت 22: پورتي را كه Daemon SSH به دنبال اتصال در آن است ، مشخص مي كند. به طور پيش فرض ، اكثر مشتري ها و سرورها در درگاه 22 كار مي كنند ، اما تغيير دادن آن به درگاه متفاوت مي تواند به طور بالقوه ميزان تلاش ورود به سيستم توسط SSH توسط كاربران مخرب را كاهش دهد.
پروتكل 2: SSH از طريق دو نسخه پروتكل بوده است. مگر اينكه به طور خاص نياز به پشتيباني مشترياني داشته باشيد كه فقط مي توانند در پروتكل 1 كار كنند ، توصيه مي شود اين موارد را رها كنيد.
كليدها و جدايي
HostKey / etc / ssh / ssh_host…: اين خطوط كليدهاي هاست را براي سرور مشخص مي كنند. از اين كليدها براي شناسايي سرور براي اتصال مشتري استفاده مي شود. اگر مشتري قبلاً با سرور ارتباط برقرار كرده باشد ، مي تواند از اين كليد براي اعتبار سنجي اتصال جديد استفاده كند.
UsePrivilegeSeparation yes: اين گزينه به SSH اجازه مي دهد تا فرآيندهاي كودك را افزايش دهد كه فقط امتيازات لازم را براي انجام وظايف خود دارند. اين يك ويژگي ايمني براي جداسازي فرايندها در صورت بهره برداري امنيتي است.
KeyRegenerationInterval and ServerKeyBits: اين گزينه ها روي كليد سرور توليد شده براي پروتكل SSH 1 تأثير مي گذارند. اگر خواستار اتصال كانكشن هاي خود به پروتكل 2 هستيد ، لازم نيست كه نگران اين موضوع باشيد.

ورود به سيستم و محدوديت ها
SyslogFacility and LogLevel : اين گزينه ها نحوه ورود به سيستم را مشخص مي كنند. گزينه اول مربوط به كد تسهيلات براي پيام هاي logging است و گزينه دوم سطح ورود به سيستم يا ميزان جزئيات را مي گويد.
LoginGraceTime 120: تعداد ثانيه هايي است كه سرور قبل از جدا شدن از مشتري در صورت عدم ورود موفق به سيستم ، منتظر مي ماند.
PermitRootLogin yes: اين گزينه امكان SSH را با استفاده از حساب root امكان پذير يا رد مي كند. از آنجا كه حساب روت يكي از مواردي است كه حمله كننده مي داند در دستگاه سرور وجود دارد و از آنجا كه دسترسي نامحدود به دستگاه را فراهم مي كند ، اغلب يك حساب كاربري بسيار هدفمند است. وقتي يك حساب كاربري معمولي را با امتيازات sudo پيكربندي كرديد تنظيم اين گزينه روي حالت “خير” توصيه مي شود.
StrictModes yes: اين به SSH مي گويد كه از پرونده هاي پيكربندي سطح كاربر كه مجوزهاي صحيحي ندارند، چشم پوشي كند. اگر كاربر پرونده هاي پيكربندي خود را به صورت جهاني قابل خواندن قرار دهد ، پيامدهاي امنيتي خواهد داشت. تا زماني كه اين مشكل برطرف شود، بهتر است دسترسي برداشته باشد.
IgnoreRhosts and RhostsRSAAuthentication : اين گزينه ها مشخص مي كند كه آيا احراز هويت به سبك rhost پذيرفته خواهد شد يا خير. اين دستور پروتكل 1 است كه در مورد پروتكل 2 صدق نمي كند.
HostbasedAuthentication no: اين نسخه پروتكل 2 از مورد فوق است. در اصل، اجازه مي دهد تا احراز هويت بر اساس ميزبان مشتري در حال اتصال انجام شود. معمولاً فقط براي محيط هاي ايزوله قابل قبول است ، زيرا امكان جعل اطلاعات منبع وجود دارد. شما مي توانيد اطلاعات ميزبان را در يك فايل /etc/ssh/shosts.equiv يا فايل /etc/hosts.equiv مشخص كنيد. اين خارج از محدوده اين راهنما ميباشد.
PermitEmptyPasswords no: اين گزينه دسترسي SSH را براي حساب هايي كه رمز عبور ندارند در هنگام تأييد رمز عبور محدود مي كند. اين مي تواند يك خطر امنيتي بزرگ باشد و تقريباً هرگز نبايد آن را تغيير دهيد.
ChallengeResponseAuthentication: اين خط يك نوع تأييد پاسخ-چالش را فعال يا غيرفعال مي كند كه مي توان از طريق PAM پيكربندي كرد. اين بحث خارج از محدوده اين راهنما است.

نمايش
X11Forwarding yes: اين گزينه به شما امكان مي دهد تا واسط هاي گرافيكي X11كاربر را براي برنامه هاي روي سرور به دستگاه مشتري منتقل كنيد. اين بدان معني است كه مي توانيد يك برنامه گرافيكي را روي يك سرور شروع كنيد، و با آن در سيستم مشتري تعامل داشته باشيد. مشتري بايد يك سيستم X در دسترس داشته باشد. مي توانيد اين موارد را در OS X نصب كنيد و هر لينوكس دسكتاپي اين قابليت را دارد.
X11DisplayOffset 10: اين يك آفست براي شماره نمايشگر sshd براي ارسال X11 است. اين افست اجازه مي دهد تا SSH باعث ايجاد پنجره هاي X11 شود تا از درگيري با سرور X موجود جلوگيري كند.
PrintMotd no: اين گزينه مشخص مي كند كه Daemon SSH نبايد پيام فايل روز را بخواند و نمايش دهد. اين گاهي اوقات توسط خود shell خوانده مي شود ، بنابراين ممكن است شما نياز به تغيير پرونده هاي ترجيحي shell خود نيز داشته باشيد.
PrintLastLog yes: اين به Daemon SSH مي گويد تا اطلاعات آخرين باري كه وارد سيستم شديد را چاپ كند.

اتصال و محيط
TCPKeepAlive yes: مشخص مي كند كه آيا پيام هاي نگهدارنده TCP به دستگاه مشتري ارسال مي شوند. اين مي تواند به سرور در هنگام بروز مشكل و قطع اتصال كمك كند. اگر اين گزينه غيرفعال باشد ، در صورت بروز مشكل در شبكه ، اتصالات از بين نمي روند ، كه مي تواند خوب باشد ، اما همچنين بدان معني است كه ارتباط كاربران مي تواند از هم قطع شود و همچنان به قفل كردن منابع ادامه دهند.
AcceptEnv LANG LC_ *: اين گزينه به شما امكان مي دهد متغيرهاي محيطي خاصي را از دستگاه مشتري قبول كنيد. در اين مثال خاص ، ما متغيرهاي زبان را مي پذيريم ، كه مي تواند به بخش shell كمك كند كه به درستي براي مشتري نمايش داده شود.
Subsystem sftp /usr/lib/openssh/sftp-serve: زير سيستم هاي خارجي را كه مي توان با SSH استفاده كرد پيكربندي مي كند. در اين مثال سرور SFTP و مسير اجراي آن مشخص شده است.
UsePAM yes: اين مشخص مي كند كه PAM (ماژول هاي تأييد قابل اتصال) براي كمك به تأييد اعتبار كاربران در دسترس خواهد بود.
اين امر به گزينه هاي پيش فرض فعال شده دستگاه Ubuntu 12.04 ما احتياج دارد. در مرحله بعدي، بگذاريد درباره برخي گزينه هاي ديگر صحبت كنيم كه ممكن است براي تنظيم يا تغيير براي شما مفيد باشد.
ساير گزينه هاي SSHD
چندين گزينه ديگر وجود دارد كه مي توانيم براي Daemon SSH خود تعيين كنيم. برخي از اين موارد ممكن است فوراً براي شما مفيد باشد ، در حالي كه برخي ديگر فقط در شرايط خاص مي توانند مفيد باشند. ما در اينجا به همه موارد نمي پردازيم ، اما برخي از موارد مفيد را مرور خواهيم كرد.
فيلتر كاربري و گروهي
برخي گزينه ها به شما امكان مي دهند دقيقاً كنترل كنيد كه كاربران از چه طريق امكان ورود به سيستم از طريق SSH را دارند. اين گزينه ها بايد به صورت انحصاري در نظر گرفته شوند. به عنوان مثال ، گزينه AllowUsers به ​​اين معني است كه از دسترسي ساير كاربران جلوگيري مي شود.
AllowGroups: اين گزينه به شما امكان مي دهد نام گروه ها را روي سرور مشخص كنيد. فقط كاربراني كه عضو يكي از اين گروه ها هستند ، مي توانند وارد سيستم شوند. اين يك ليست سفيد از گروه هايي ايجاد مي كند كه بايد دسترسي داشته باشند.
AllowUsers: مشابه گزينه فوق است ، اما كاربران خاصي را كه مجاز به ورود به سيستم هستند مشخص مي كند. هر كاربر كه در اين ليست نباشد قادر به ورود به سيستم نخواهد بود. و به عنوان يك ليست سفيد كاربري كار مي كند.
DenyGroups: اين گزينه يك ليست سياه از گروههايي را ايجاد مي كند كه نبايد اجازه ورود به سيستم را داشته باشند. كاربراني كه به اين گروه ها تعلق دارند ، اجازه دسترسي ندارند.
DenyUsers: اين يك ليست سياه براي كاربران است. به طور خاص مشخص مي كند كه به كدام يك از كاربران امكان ورود به سيستم از طريق SSH داده نمي شود.
علاوه بر اين ، برخي از گزينه هاي محدود كننده ديگر نيز در دسترس هستند. اينها را مي توان در رابطه با هر يك از گزينه هاي فوق استفاده كرد:
Match: اين گزينه امكان كنترل بسيار دقيق تر بر روي افرادي را دارد كه تحت چه شرايطي مي توانند تأييد كنند. اين مجموعه گزينه هاي متفاوتي را مشخص مي كند كه هنگام اتصال يك كاربر يا گروه خاص بايد از آنها استفاده شود. ما بعداً با جزئيات بيشتري در مورد اين موضوع بحث خواهيم كرد.
RevokenKeys: اين به شما امكان مي دهد ليستي از كليدهاي عمومي ابطال شده را مشخص كنيد. اين كار از ورود كليدهاي ذكر شده براي ورود به سيستم جلوگيري مي كند.
گزينه هاي متفرقه
گزينه هايي وجود دارد كه مي توانيم از آنها استفاده كنيم تا پيكربندي كنيم چه ترافيك شبكه اي را Daemon SSH به آن توجه خواهد كرد:
AddressFamily: اين گزينه مشخص مي كند كه چه نوع آدرس هايي را انتخاب مي كنيد كه اتصالات آن ها را بپذيريد. به طور پيش فرض ، مقدار “هر” است ، اما مي توانيد “inet” را براي آدرسهاي IPv4 يا “inet6” را براي آدرسهاي IPv6 قرار دهيد.
ListenAddress: اين گزينه به شما امكان مي دهد تا به Daemon SSH بگوييد كه در يك آدرس و پورت خاص گوش كند. Daemon به طور پيش فرض تمام آدرسهايي را كه براي اين دستگاه پيكربندي شده است گوش مي دهد.
انواع ديگر گزينه هايي كه در دسترس هستند عبارتند از مواردي كه براي تنظيم تأييد هويت مبتني بر گواهينامه ، گزينه هاي محدود كننده اتصال مانند ClientAliveCountMax و ClientAliveInterval و گزينه هايي مانند ChrootDirectory استفاده مي شود ، كه مي تواند براي قفل كردن ورود به سيستم كاربر به يك فضاي خاص و محيط از پيش تنظيم شده Chroot استفاده شود. .
محدود كردن ورود به سيستم كاربر
ما در بالا به برخي از ابزارهايي كه شما بايد دسترسي كاربران و گروه ها را محدود كنيد ، اشاره كرديم. بياييد كمي با جزئيات بيشتر بحث كنيم.
ابتدايي ترين دستور براي استفاده از اين موارد چيزي شبيه به زير است:
AllowUsers demouser fakeuser madeupuser

همانطور كه مشاهده مي كنيد، ما مي توانيم كاربرهاي مختلفي را از هم جدا كنيم كه در هر يك از اين دستورالعمل ها قرار دارند.
ما همچنين مي توانيم از wild cards استفاده كرده و ورودي ها را نفي كنيم. به عنوان مثال ، اگر مي خواستيم به همه كاربرها به جز “جان” اجازه ورود به سيستم بدهيم ، مي توانيم چيزي شبيه به اين را امتحان كنيم:
AllowUsers * !john
اين نمونه خاص احتمالاً با خط DenyUsers بهتر بيان مي شود:

DenyUsers john
ما همچنين مي توانيم از علامت ? براي مطابقت دقيق با يك حرف استفاده كنيم، به عنوان مثال ميتوانيم از دستور زير استفاده كنيم:

AllowUsers ?im

اين كار اجازه مي دهد تا از حساب هايي مانند “tim” ، “jim” يا “vim” وارد شويد.
با اين حال ما مي توانيم مشخص تر شويم. در هر دو مشخصات كاربر ، مي توانيم از فرم كاربر user@hostname استفاده كنيم تا ورود به مكانهاي منبع خاص مشتري محدود شود. به عنوان مثال ، شما مي توانيد چيزي مانند دستور زير را تايپ كنيد:
AllowUsers demouser@host1.com fakeuser

اين كار باعث مي شود “fakeuser” از هرجاي ديگري وارد سيستم شود ، اما فقط به “demouser” اجازه مي دهد تا از يك هاست مشخص وارد شود.
ما همچنين مي توانيم دسترسي را به صورت ميزبان به ميزبان در خارج از فايل sshd_config از طريق بسته هاي TCP محدود كنيم. اين از طريق فايل هاي /etc/hosts.allow و /etc/hosts.deny پيكربندي ميشود.
به عنوان مثال ، ما مي توانيم دسترسي را به طور خاص بر اساس ترافيك SSH با اضافه كردن خط هايي مانند زير به فايل hosts.allow محدود كنيم:
sshd: .example.com

با فرض اينكه ما در فايل hosts.deny يك خط همراه داريم كه به صورت زير است:
sshd: ALL
اين كار ورود به سيستم را فقط براي افرادي كه از example.com يا يك زير دامنه وارد مي شوند محدود مي كند.
استفاده از گزينه هاي مطابقت براي اضافه كردن استثنائات
ما مي توانيم با استفاده از گزينه هاي “match” گزينه هاي خود را حتي بيشتر كنترل كنيم. گزينه هاي مطابقت با مشخص كردن الگوي معياري كار ميكنند كه تصميم مي گيرند كه گزينه هاي زير استفاده خواهد شد يا خير.
ما يك مطابقت را با استفاده از گزينه Match و سپس مشخص كردن جفت هاي معياري با ارزش كليدي شروع مي كنيم. كليدهاي موجود “كاربر” ، “گروه” ، “ميزبان” و “آدرس” هستند. ما مي توانيم معيارها را با فاصله جدا كنيم و الگوها (user1، user2) را با كاما از هم جدا كنيم. ما همچنين مي توانيم از wild cards و خنثي سازي استفاده كنيم:
Match User !demouser,!fakeuser Group sshusers Host *.example.com

خط بالا فقط در صورتي مطابقت دارد كه كاربر demouser يا fakeuser نباشد ، در صورتي كه كاربر عضو گروه sshusers باشد و در صورت اتصال آن از example.com يا يك زير دامنه استفاده كند.
معيارهاي “آدرس” مي توانند از نماد net Cask CIDR استفاده كنند.
گزينه هايي كه از مشخصات مطابقت پيروي مي كنند بصورت مشروط اعمال مي شوند. دامنه اين گزينه هاي شرطي تا پايان پرونده يا مشخصات مطابقت بعدي است. به همين دليل توصيه مي شود مقادير پيش فرض خود را در بالاي فايل قرار دهيد و استثنائات خود را در انتهاي آن قرار دهيد.

به دليل اين بلوك شرطي ، گزينه هاي موجود تحت مطابقت اغلب بيان ميكنند كه فقط در انطباق فوق اعمال مي شوند. به عنوان مثال ، شرط فوق مي تواند بلوكي مانند اين تحت آن داشته باشد:
Match User !demouser,!fakeuser Group sshusers Host *.example.com
AuthorizedKeysFile /sshusers/keys/%u
PasswordAuthentication yes
X11Forwarding
X11DisplayOffset 15

شما فقط هنگام برخورد با مشخصات انطباق به زير مجموعه گزينه ها دسترسي داريد. براي ديدن ليست كامل ، صفحه sshd_config را ببينيد:
man sshd_config

براي ديدن ليست گزينه هاي موجود ، بخش “مطابقت” را جستجو كنيد.
نتيجه
همانطور كه مشاهده مي كنيد ، مي توانيد مقادير زيادي را در سمت سرور SSH تنظيم كنيد كه در توانايي كاربران براي ورود به سيستم و كيفيت تجربه آنها تأثير مي گذارد. اطمينان حاصل كنيد كه تغييرات خود را قبل از اجراي مقياس گسترده با دقت آزمايش كنيد تا خطاها را پيدا كنيد و اطمينان حاصل كنيد كه محدوديت هاي شما به طور تصادفي روي تعداد كمي از كاربران يا تعداد خيلي زيادي تأثير نمگذارد.
آشنايي با فايل / etc / ssh / sshd_config اولين قدم بزرگ در جهت درك چگونگي كنترل دقيق دسترسي به سرور شماست. و يك مهارت مهم براي هر مدير سيستم لينوكس ميباشد.


برچسب: ،
بازدید:

ادامه مطلب

نوشته شده: ۸ بهمن ۱۳۹۸ساعت: ۰۱:۲۵:۳۰ توسط:server موضوع:

نحوه نصب وردپرس با OpenLiteSpeed ​​در اوبونتو 18.04

مقدمه
WordPress يك سيستم مديريت محتواي منبع باز (CMS) است. WordPress محبوب ترين CMS در جهان است كه به شما امكان مي دهد تا وبلاگ ها و وب سايت هايي را فراتر از پايگاه داده MySQL تنظيم كنيد ، از PHP براي اجراي اسكريپت ها و پردازش محتواي پويا استفاده كنيد.
OpenLiteSpeed ​​ يك سرور وب منبع باز بهينه شده است كه مي توانيد از آن براي مديريت و سرويس وب سايت ها استفاده كنيد. OpenLiteSpeed ​​ داراي برخي ويژگي هاي مفيد است كه آن را به گزينه اي مناسب براي بسياري از نصب ها تبديل مي كند: قوانين بازنويسي سازگار با Apache، يك رابط كاربري مديريت مبتني بر وب و پردازش PHP سفارشي براي بهينه سازي سرور.
اين راهنما روند نصب و تنظيم يك نمونه وردپرس را در Ubuntu 18.04 با استفاده از وب سرور OpenLiteSpeed ​​طي خواهد كرد. از آنجا كه هم WordPress و OpenLiteSpeed ​​مي توانند از طريق يك مرورگر وب مديريت شوند ، اين پيكربندي براي كساني كه دسترسي منظم به بخش SSH ندارند يا كساني كه ممكن است احساس راحتي مديريت يك سرور وب از طريق خط فرمان را نداشته باشند ، ايده آل است.
پيش نيازها
قبل از شروع اين راهنما به موارد زير نياز خواهيد داشت:
يك سرور كه Ubuntu 18.04 را اجرا ميكند با يك ادمين، يك كاربر غير روت و فايروال با استفاده از ufw پيكربندي كرده است. براي تنظيم اين محيط ، آموزش اوليه سرور ما را براي اوبونتو 18.04 دنبال كنيد.
OpenLiteSpeed ​​ بر روي سرور شما نصب شده است. براي راهنمايي در مورد نصب و پيكربندي OpenLiteSpeed ​​به راهنماي ما در مورد نحوه نصب OpenLiteSpeed ​​وب سرور در اوبونتو 18.04 مراجعه كنيد.
MySQL بر روي سرور شما نصب شده است. براي تنظيم اين روش نحوه نصب MySQL را در اوبونتو 18.04 دنبال كنيد.
مرحله 1 – ايجاد يك بانك اطلاعاتي و كاربر بانك اطلاعاتي براي وردپرس
WordPress از MySQL براي مديريت و ذخيره اطلاعات سايت و كاربر استفاده مي كند. شما قبلاً MySQL را نصب كرده ايد ، اما به عنوان يك مرحله مقدماتي به ايجاد يك بانك اطلاعاتي و يك كاربر براي استفاده از وردپرس نياز داريد.
براي شروع كار ، با استفاده از SSH به سرور خود وصل شويد:
ssh sammy @ your_server_IP
سپس وارد حساب ريشه MySQL شويد:

sudo mysql

توجه: اگر مرحله 3 را در پيش نياز آموزش MySQL به پايان رسانده ايد و كاربر root MySQL را براي تأييد اعتبار با افزونه mysql_native_password پيكربندي كرده ايد ، بايد دستور زير را وارد كنيد:
mysql -u root -p

سپس در صورت درخواست رمزعبور كاربر اصلي خود را وارد كنيد.
از تبليغ MySQL ، يك پايگاه داده با دستور زير ايجاد كنيد. در اينجا ، ما اين ديتابيس را براي سادگي وردپرس نام مي گذاريم ، اما شما مي توانيد آن را هرچه دوست داريد نامگذاري كنيد:
CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
سپس ، يك كاربر ايجاد كرده و به آن امتيازات بانك اطلاعاتي كه اخيراً ايجاد كرده ايد بدهيد. باز هم ، مي توانيد هر نامي را به اين كاربر بدهيد ، اما براي سادگي ما آن را wordpressuser مي ناميم. همچنين ، حتماً گذرواژه را به يك رمز عبور قوي با انتخاب خود تغيير دهيد:
GRANT ALL PRIVILEGES ON wordpress.* TO ‘wordpressuser’@’localhost’ IDENTIFIED BY ‘password’;
سپس ، PRUSILEGES FLUSH را اجرا كنيد كه به سرور مي گويد جداول اعطاي امتياز را مجدد لود كند و اعمال تغييرات جديد خود را اجرا كنيد ،:
FLUSH PRIVILEGES;
پس از آن ، مي توانيد اعلان MySQL را ببنديد:
exit
اكنون نصب MySQL خود براي كار با WordPress را انجام داده ايد. در مرحله بعد چند افزونه PHP نصب خواهيم كرد.

مرحله 2 – نصب افزونه هاي اضافي PHP
در آموزش پيش نياز OpenLiteSpeed ​​، بسته lsphp73 را نصب كرديد. اين مجموعه اي از PHP بهينه شده براي OpenLiteSpeed ​​ است كه از LiteSpeed ​​SAPI براي ارتباط با برنامه هاي خارجي استفاده مي كند. بسته به نياز شما ، وردپرس ممكن است نياز به ساير افزونه هاي PHP داشته باشد تا بتواند به دلخواه عمل كند.

براي نصب برخي افزونه هاي PHP كه معمولاً با WordPress استفاده مي شود ، دستور زير را اجرا كنيد:
sudo apt install lsphp73-common lsphp73-curl lsphp73-imagick lsphp73-imap lsphp73-json lsphp73-memcached lsphp73-mysql lsphp73-opcache lsphp73-redis
توجه: بسته هاي اين دستور ممكن است تمام موارد استفاده را پوشش ندهد. براي يك ليست كامل از افزونه هاي PHP 7.3 موجود از مخزن LiteSpeed ​​كه در آموزش پيش نياز به سرور خود اضافه كرده ايد ، به Wiki LiteSpeed ​​مراجعه كنيد.
پس از اين ، مي توانيد به سمت دانلود و تنظيم وردپرس در سرور خود برويد.
مرحله 3 – دانلود وردپرس
اكنون كه نرم افزار سرور شما پيكربندي شده است ، مي توانيد WordPress را نصب و تنظيم كنيد. به ويژه به دلايل امنيتي ، هميشه توصيه مي شود كه آخرين نسخه وردپرس را مستقيماً از سايت خودشان دريافت كنيد.
به يك ديركتوري قابل نوشتار برويد و سپس نسخه فشرده شده را با تايپ كردن دستور زير دانلود كنيد:
cd /tmp
curl -O https://wordpress.org/latest.tar.gz
براي ايجاد ساختار دايركتوري وردپرس ، فايل فشرده شده را استخراج كنيد:
tar xzvf latest.tar.gz
ما اين پرونده ها را لحظه به لحظه به ريشه سند منتقل خواهيم كرد ، اما ابتدا چند فايل و فهرست را ايجاد خواهيم كرد كه نصب وردپرس به آنها بستگي دارد.
OpenLiteSpeed ​​ از فايل هاي .htaccess پشتيباني مي كند. اين براي اهداف ما مهم است ، از آنجا كه وردپرس
از فايلهاي .htaccess براي ايجاد و مديريت پرونده هاي ثابت استفاده مي كند.
يك فايل .htaccess ساختگي اضافه كنيد تا بعداً براي استفاده وردپرس در دسترس باشد:
touch /tmp/wordpress/.htaccess

سپس ، فايل پيكربندي نمونه را بر روي نام خانوادگي كه وردپرس ميخواند، كپي كنيد:
cp /tmp/wordpress/wp-config-sample.php /tmp/wordpress/wp-config.php
علاوه بر اين ، دايركتوري upgrade را ايجاد كنيد تا وردپرس هنگام تلاش براي انجام اين كار به تنهايي و به دنبال بروزرساني در نرم افزار خود ، به مشكلات مربوط به مجوزها برخورد نكند:

mkdir /tmp/wordpress/wp-content/upgrade
سپس كل محتواي فهرست را در روت سند خود كپي كنيد.OpenLiteSpeed ​​ با يك ميزبان مجازي پيش فرض به نام Example در ديركتوري / usr / local / lsws / قرار دارد. روت سند براي ميزبان مجازي Example زيرمجموعه html است:
sudo cp -a /tmp/wordpress/. /usr/local/lsws/Example/html/wordpress
توجه كنيد كه اين دستور شامل يك نقطه در انتهاي فهرست منبع است تا نشان دهد كه همه چيزهاي داخل ديركتوري بايد كپي شوند ، از جمله پرونده هاي مخفي (مانند پرونده .htaccess كه ايجاد كرديد):
با اين كار ، شما وردپرس را با موفقيت روي سرور وب خود نصب كرده ايد و برخي از مراحل اوليه تنظيمات را انجام داده ايد. در مرحله بعد ، ما تغييرات ديگري را در پيكربندي انجام خواهيم داد كه امتيازات وردپرس را براي عملكرد ايمن و دسترسي به بانك اطلاعاتي MySQL و حساب كاربري كه قبلاً ايجاد كرده ايد به شما مي دهد.
مرحله 4 – پيكربندي دايركتوري وردپرس
قبل از اينكه بتوانيم فرآيند راه اندازي مبتني بر وب را براي وردپرس طي كنيم ، بايد برخي موارد را در دايركتوري وردپرس خود تنظيم كنيم.
با دادن مالكيت كليه فايل هاي موجود در ديركتوري به كاربر nobody و گروه nogroup ، كه وب سرور OpenLiteSpeed ​​بصورت پيش فرض اجرا مي كند ، شروع كنيد. دستور chown زير به OpenLiteSpeed ​​امكان خواندن و نوشتن فايل ها در دايركتوري وردپرس را اعطا مي كند ، و اين امكان را براي سرويس دهي به وب سايت و انجام به روز رساني هاي خودكار فراهم مي كند:
sudo chown -R nobody:nogroup /usr/local/lsws/Example/html/wordpress
براي تنظيم مجوزهاي صحيح در دايركتوري ها و فايل هاي وردپرس ، دو دستور find اجرا كنيد:
sudo find /usr/local/lsws/Example/html/wordpress/ -type d -exec chmod 750 {} ;
sudo find /usr/local/lsws/Example/html/wordpress/ -type f -exec chmod 640 {} ;
اينها بايد مجوزهاي معقولي براي شروع باشد ، اگرچه برخي از افزونه ها و رويه ها ممكن است نياز به ترفندهاي اضافي داشته باشند.
پس از اين ، شما بايد تغييراتي در پرونده اصلي پيكربندي WordPress انجام دهيد.
با باز كردن فايل ، اولين هدف شما تنظيم برخي كليدهاي مخفي براي ايجاد امنيت براي نصب شما خواهد بود. WordPress يك مولد مطمئن براي اين مقادير فراهم مي كند به طوري كه ديگر نيازي به تلاش براي دستيابي به مقادير خوب از خودتان نيست. اينها فقط به صورت داخلي استفاده مي شود ، بنابراين به مقادير پيچيده و ايمن در اينجا آسيب نمي رساند.
براي گرفتن مقادير ايمن از مولد كليد مخفي WordPress ، تايپ كنيد:
curl -s https://api.wordpress.org/secret-key/1.1/salt/
شما به مقادير منحصر به فردي بر مي گرديد كه چيزي شبيه به اين است:

هشدار! مهم است كه هر بار درخواست مقادير منحصر به فرد كنيد. مقادير نشان داده شده در زير را كپي نكنيد!

خروجي
define(‘AUTH_KEY’, ‘1jl/vqfs define(‘SECURE_AUTH_KEY’, ‘E2N-h2]Dcvp+aS/p7X DO NOT COPY THESE VALUES {Ka(f;rv?Pxf})CgLi-3’);
define(‘LOGGED_IN_KEY’, ‘W(50,{W^,OPB%PB define(‘NONCE_KEY’, ‘ll,4UC)7ua+8سرور وب داده شده است كه در هر جا لازم است بنويسيم، مي توانيم به طور صريح روش سيستم فايل را به direct تنظيم كنيم. عدم تنظيم اين با تنظيمات فعلي ما منجر به اعلان وردپرس براي اعتبار FTP در هنگام برخي عملكردهاي خاص ميشود. اين تنظيمات مي تواند در زير تنظيمات اتصال ديتابيس يا هر جاي ديگر فايل اضافه شود: /var/www/wordpress/wp-config.php . . . define(‘DB_NAME’, ‘wordpress’); /** MySQL database username */ define(‘DB_USER’, ‘wordpressuser’); /** MySQL database password */ define(‘DB_PASSWORD’, ‘password’); . . . define(‘FS_METHOD’, ‘direct’); هنگامي كه كارتان تمام شد، فايل را ذخيره كنيد و ببنديد. در اين مرحله ، وردپرس كاملاً در سيستم شما پيكربندي نشده است ، زيرا هنوز لازم است قبل از شروع انتشار مطالب ، چند كار نهايي را اعمال كنيد. براي انجام اين كار ، ابتدا لازم است چند تغيير تنظيمات در نصب OpenLiteSpeed خود اعمال كنيد. مرحله 6 – پيكربندي OpenLiteSpeed در حال حاضر ، شما WordPress را در سرور Ubuntu خود نصب كرده ايد ، اما نصب OpenLiteSpeed ​​شما هنوز براي ارائه آن تنظيم نشده است. در اين مرحله ، ما به رابط اجرايي OpenLiteSpeed ​​دسترسي خواهيم داشت و چند تغيير در پيكربندي سرور شما ايجاد مي كنيم. در مرورگر وب مورد نظر خود، به رابط اداري OpenLiteSpeed ​​برويد. مي توانيد اين را با وارد كردن آدرس IP عمومي سرور خود يا نام دامنه مرتبط با آن ، و به دنبال آن: 7080 در نوار آدرس مرورگر خود بيابيد: https: // server_domain_or_IP: 7080 در آنجا به شما يك صفحه ورود به سيستم ارائه مي شود. نام كاربري و رمز عبوري را كه در آموزش پيش نياز OpenLiteSpeed ​​تعريف كرده ايد وارد كنيد: از كنسول OpenLiteSpeed ​​، در منوي نوار كناري سمت چپ ، بر روي تنظيمات سرور كليك كنيد. سپس به سربرگ External App برويد ، رديف برنامه LiteSpeed ​​SAPI را پيدا كنيد و بر روي دكمه Edit آن كليك كنيد: به ياد بياوريد كه در پيش نياز آموزش OpenLiteSpeed ​​، بسته lsphp73 را نصب كرديد ، تلفيقي از PHP بهينه سازي شده براي كار با OpenLiteSpeed ​​از طريق LiteSpeed ​​SAPI. با اين حال ، تنظيمات پيش فرض در صفحه External App به lsphp اشاره دارد نه lsphp73. به همين دليل ، نصب OpenLiteSpeed ​​شما قادر به اجراي صحيح اسكريپت هاي PHP نيست. براي تصحيح اين امر ، قسمت Name را به lsphp73 تغيير دهيد ، قسمت آدرس را به uds: //tmp/lshttpd/lsphp73.sock تغيير دهيد و قسمت Command را به SERVER_ROOT / lsphp73 / bin / lsphp: پس از ايجاد آن تغييرات ، روي آيكون save در گوشه سمت راست بالاي كادر LiteSpeed ​​SAPI App كليك كنيد. سپس، در منوي سمت چپ روي Virtual Hosts كليك كنيد. در صفحه Virtual Hosts ميزبان مجازي مورد نظر خود را پيدا كنيد و بر روي نماد View آن كليك كنيد. در اينجا ، ما از هاست مجازي مثال پيش فرض استفاده خواهيم كرد: به سربرگ General هاست مجازي برويد. در آنجا بخش General را پيدا كنيد و روي دكمه edit آن كليك كنيد: OpenLiteSpeed ​​ براي ارائه خدمات به دنبال محتويات Document Root ميگردد. از آنجا كه تمام مطالب و فايل هاي وردپرس شما در ديركتوري وردپرس كه قبلا ايجاد شده ذخيره مي شوند، قسمت Document Root را به روز كنيد تا به آن ديركتوري راهنمايي كنيد. براي انجام اين كار ، تنها كاري كه بايد انجام دهيد اضافه كردن وردپرس / به پايان مقدار پيش فرض است: براي ذخيره اين تغيير، روي آيكون save كليك كنيد. در مرحله بعد ، بايد پرونده هاي index.php را فعال كنيد تا از آنها براي پردازش درخواست هايي كه توسط پرونده هاي استاتيك مديريت نمي شوند ، استفاده شود. با اين كار منطق اصلي وردپرس به درستي كار مي كند. در حالي كه هنوز در تب General هستيد، براي يافتن بخش Index Files به پايين برويد و بر روي نماد edit آن كليك كنيد: در قسمت Index Files ، index.html را با index.php پيش ببريد. با قرار دادن index.php قبل از index.html ، به فايلهاي شاخص PHP اجازه مي دهيد كه اولويت داشته باشند. پس از به روزرساني اين قسمت ، مانند عكس خواهد بود قبل از ادامه ، روي آيكون save كليك كنيد. در مرحله بعد ، به سربرگ Rewrite هاست مجازي برويد. بخش Rewrite Control را پيدا كنيد و دكمه ويرايش را فشار دهيد: با كليك بر روي دكمه هاي شعاعي مربوطه ، هر دو گزينه Enable Rewrite و Auto Load را از گزينه هاي .htaccess روي Yes بگذاريد. پيكربندي دستورالعمل هاي بازنويسي در اين روش به شما امكان مي دهد از نصب مجدد لينك ها در نصب وردپرس خود استفاده كنيد: بعد از انجام تغييرات ، روي ذخيره كليك كنيد. هاست مجازي پيش فرض كه همراه با نصب OpenLiteSpeed ​​است شامل برخي از نواحي محافظت شده با رمز عبور براي نمايش ويژگي هاي تأييد اعتبار كاربر OpenLiteSpeed. است. WordPress شامل مكانيزم هاي تأييد اعتبار خاص خود است و ما از هويت مبتني بر پرونده موجود در OpenLiteSpeed ​​استفاده نخواهيم كرد. براي به حداقل رساندن بخش هاي پيكربندي انحرافي فعال در نصب وردپرس ما بايد از اين موارد خلاص شويم. ابتدا بر روي زبانه Security كليك كرده و سپس بر روي دكمه Delete كنار SampleProtectedArea در جدول Realms List كليك كنيد: از شما خواسته مي شود حذف را تأييد كنيد. براي ادامه بر روي delete كليك كنيد در مرحله بعد ، روي سربرگ Context كليك كنيد. در Context List ، محتواي /protected/ را كه با قلمرو امنيتي كه اخيراً حذف كرديد مرتبط بود را حذف كنيد: مجدداً بايد با كليك كردن روي delete ، حذف را تأييد كنيد. شما مي توانيد با اطمينان با استفاده از همان تكنيك ، همه متن هاي ديگر را پاك كنيد ، زيرا ما به آنها احتياج نخواهيم داشت. ما به طور خاص محتواي /protected/ متن را حذف كرديم زيرا در غير اين صورت خطايي به دليل حذف قلمرو امنيت مرتبط با آن ايجاد مي شود (كه ما فقط در تب Security حذف كرده ايم.) پس از آن ، در گوشه سمت راست بالاي كنسول OpenLiteSpeed ​​، آيكون Graceful Restart را فشار دهيد. با اين كار سرور OpenLiteSpeed ​​ دوباره راه اندازي مي شود و باعث مي شود تغييراتي كه ايجاد كرده ايد به مرحله اجرا برسد: با اين كار ، سرور OpenLiteSpe شما كاملاً پيكربندي شده است. اكنون آماده تنظيم وردپرس در مرورگر خود هستيد. مرحله 7 – تكميل نصب از طريق واسط وردپرس اكنون كه پيكربندي سرور كامل شد ، مي توانيم نصب را از طريق رابط وب انجام دهيم. در مرورگر وب خود ، به نام دامنه سرور يا آدرس IP عمومي خود برويد: http: // server_domain_or_IP زباني را كه مي خواهيد استفاده كنيد انتخاب كنيد: در مرحله بعد به صفحه اصلي تنظيمات خواهيد رسيد. يك نام براي سايت وردپرس خود انتخاب كنيد و يك نام كاربري را انتخاب كنيد (توصيه مي شود براي اهداف امنيتي چيزي مانند “ادمين” انتخاب نكنيد). رمزعبور قوي به صورت خودكار ايجاد مي شود. اين رمز عبور را ذخيره كنيد يا يك رمزعبور قوي ديگر را انتخاب كنيد. آدرس ايميل خود را وارد كنيد و انتخاب كنيد آيا مي خواهيد موتورهاي جستجو را از ايندكس كردن سايت خود منع كنيد: پس از آماده شدن ، روي دكمه Install WordPress كليك كنيد. شما به صفحه اي منتهي مي شويد كه وارد سيستم شويد: پس از ورود به سيستم ، شما به داشبورد مديريت وردپرس منتقل مي شويد: از داشبورد ، مي توانيد تغييراتي در تم سايت خود و انتشار محتواي آن ايجاد كنيد. نتيجه با تكميل اين راهنما ، يك نمونه وردپرس را روي سرور اوبونتو 18.04 كه OpenLiteSpeed ​​را اجرا مي كند ، نصب و پيكربندي كرديد. برخي مراحل متداول بعدي بايد براي تنظيمات پيوند مجدد پست هاي شما انتخاب شوند (كه مي توانيد در Settings > Permalinksپيدا كنيد) يا انتخاب يك تم جديد (در Appearance > Themes). اگر اين اولين باري است كه از WordPress استفاده مي كنيد ، كمي رابط را جستجو كنيد تا با CMS جديد خود آشنا شويد.
براي افزايش امنيت سايت جديد وردپرس خود ، توصيه مي كنيم آن را پيكربندي كنيد تا با SSL كار كند تا بتواند از طريق HTTPS محتوا را ارائه دهد. براي نصب LetsEncrypt و تنظيم اين آموزش ، از اسناد OpenLiteSpeed ​​بازديد كنيد.


برچسب: ،
بازدید:

ادامه مطلب

نوشته شده: ۸ بهمن ۱۳۹۸ساعت: ۰۱:۲۵:۰۹ توسط:server موضوع:

نحوه نصب Apache Kafka در Debian 10

Apache Kafka يك كارگزار پيام توزيع شده محبوب است كه براي مديريت حجم زيادي از داده هاي زمان-واقعي طراحي شده است. خوشه كافكا بسيار مقياس پذير و داراي تحمل خطا است و همچنين نسبت به ساير واسطه هاي پيام مانند ActiveMQ و RabbitMQ از توان بسيار بالاتري برخوردار است. اگرچه معمولاً از آن به عنوان يك سيستم پيام رسان انتشار / اشتراك استفاده مي شود ، بسياري از سازمان ها نيز از آن براي جمع آوري ورود به سيستم استفاده مي كنند زيرا فضاي ذخيره سازي مداوم را براي پيام هاي منتشر شده ارائه مي دهد.
يك سيستم پيام رساني انتشار / اشتراك به يك يا چند توليد كننده اجازه مي دهد پيام ها را بدون در نظر گرفتن تعداد مصرف كنندگان يا نحوه پردازش پيام ها منتشر كنند. متقاضيان داراي اشتراك در مورد به روزرساني ها و ايجاد پيام هاي جديد بطور خودكار مطلع مي شوند. اين سيستم نسبت به سيستم هايي كه مشتري ها بطور دوره اي در مورد آن نظرسنجي مي شوند تا مشخص شود كه آيا پيام هاي جديد در دسترس است يا خير، بسيار كارآمدتر و مقياس پذير است.
در اين آموزش ، Apache Kafka 2.1.1 را به صورت ايمن روي سرور Debian 10 نصب و پيكربندي مي كنيد ، سپس با توليد و استفاده از يك پيام Hello World راه اندازي خود را تست مي كنيد. سپس مي توانيد KafkaT را به صورت اختياري براي نظارت بر كافكا نصب كنيد و يك خوشه چند گره كافكا را تنظيم كنيد.
پيش نيازها
براي دنبال كردن ، به موارد زير نياز خواهيد داشت:
يك سرور Debian 10 با حداقل 4 گيگابايت رم و يك كاربر غير ريشه با امتيازات سودو. در صورتي كه كاربر غير ريشه تنظيم نكرده ايد، مراحل ذكر شده در راهنماي راه اندازي سرور اوليه براي Debian 10 را دنبال كنيد.
OpenJDK 11 روي سرور شما نصب شده است. براي نصب اين نسخه ، دستورالعمل هاي نصب Java را با Apt در Debian 10 در مورد نصب نسخه هاي خاص OpenJDK دنبال كنيد. كافكا در جاوا نوشته شده است ، بنابراين به JVM نياز دارد.
توجه: نصب هاي بدون رم 4 گيگابايتي ممكن است باعث شود سرويس كافكا از كار بيفتد، در حالي كه دستگاه مجازي جاوا (JVM) در هنگام راه اندازي يك استثناء Out Of Memory را به همراه داشته باشد.
مرحله 1 – ايجاد كاربر براي كافكا
از آنجا كه كافكا مي تواند درخواست ها را از طريق شبكه انجام دهد ، بهترين كار براي ايجاد يك كاربر اختصاصي براي آن است. در صورت به خطر افتادن سرور كافكا ، اين كار آسيب به دستگاه Debian شما را به حداقل مي رساند. در اين مرحله شما كاربر اختصاصي كافكا را ايجاد خواهيد كرد.
به عنوان كاربر sudo غير ريشه خود وارد شويد ، با دستور useradd كاربري بنام kafka بسازيد:
sudo useradd kafka -m
فلگ -m تضمين مي كند كه يك هوم ديركتوري براي كاربر ايجاد مي شود. اين هوم ديركتوري، / home / kafka ، بعداً به عنوان ديركتوري فضاي كاري شما براي اجراي دستورات عمل خواهد كرد.

رمز عبور را با استفاده از passwd تنظيم كنيد:
sudo passwd kafka
رمز عبوري را كه مي خواهيد براي اين كاربر استفاده كنيد وارد كنيد.
در مرحله بعدي ، كاربر كافكا را با دستور adduser به گروه سودو اضافه كنيد ، تا امتيازات لازم براي نصب وابستگي كافكا را داشته باشد:
sudo adduser kafka sudo
كاربر kafka شما اكنون آماده است. با استفاده از su وارد اين حساب شويد:
su -l kafka
اكنون كه كاربر اختصاصي كافكا را ايجاد كرده ايد ، مي توانيد به دانلود و استخراج باينري هاي كافكا برويد.
مرحله 2 – دانلود و استخراج باينري هاي كافكا
در اين مرحله، باينري هاي كافكا را در پوشه هاي اختصاصي در ديركتوري هوم كاربر kafka خود دانلود و اكستركت مي كنيد.
براي شروع ، دايركتوري را در / home / kafka با نام Downloads براي ذخيره دانلودهاي خود ايجاد كنيد:
mkdir ~/Downloads
در مرحله بعدي، حلقه را با استفاده از apt-get نصب كنيد تا بتوانيد فايلهاي از راه دور را دانلود كنيد:
sudo apt-get update && sudo apt-get install curl
در صورت درخواست، Y را تايپ كنيد تا دانلود curl را تأييد كنيد.
پس از نصب Curl ، از آن براي دانلود باينري هاي كافكا استفاده كنيد:
curl “https://archive.apache.org/dist/kafka/2.1.1/kafka_2.11-2.1.1.tgz” -o ~/Downloads/kafka.tgz
دايركتوري به نام kafka ايجاد كنيد و به اين فهرست تغيير دهيد. اين دايركتوري پايه نصب كافكا خواهد بود:
mkdir ~/kafka && cd ~/kafka
با استفاده از دستور tar ، آرشيوي را كه دانلود كرده ايد استخراج كنيد:
tar -xvzf ~/Downloads/kafka.tgz –strip 1
شما فلگ –strip 1 را براي اطمينان از استخراج محتواي بايگاني در ~ / kafka / و نه در ديركتوري ديگري در داخل آن ، مانند ~ / kafka / kafka_2.12-2.1.1 / مشخص كرده ايد.
اكنون كه باينري ها را با موفقيت دانلود و استخراج كرده ايد ، مي توانيد پيكربندي كافكا را انجام دهيد تا امكان حذف موضوع فراهم شود.
مرحله 3 – پيكربندي سرور كافكا
رفتار پيش فرض كافكا به ما اجازه نمي دهد تا عنوان، دسته بندي، گروه يا نام فيد را براي انتشار پيام ها حذف كنيم. براي تغيير اين، پرونده پيكربندي را ويرايش مي كنيد.
گزينه هاي پيكربندي كافكا در server.properties مشخص شده است. اين پرونده را با nano يا ويرايشگر مورد علاقه خود باز كنيد:
nano ~/kafka/config/server.properties
بياييد تنظيماتي را اضافه كنيم كه به ما امكان حذف عناوين كافكا را مي دهد. خط هايلايت شده زير را در زير فايل اضافه كنيد:
~/kafka/config/server.properties

group.initial.rebalance.delay.ms

delete.topic.enable = true

فايل را ذخيره كنيد و از nano خارج شويد. اكنون كه Kafka را پيكربندي كرده ايد، مي توانيد براي راه اندازي و فعال كردن كافكا در هنگام راه اندازي فايل هاي واحد systemed ايجاد كنيد.
مرحله 4 – ايجاد فايلهاي واحد سيستمي و راه اندازي سرور كافكا
در اين بخش فايلهاي واحد سيستمي براي سرويس كافكا ايجاد مي كنيد. اين به شما كمك مي كند تا خدمات متداول مانند شروع، متوقف كردن و راه اندازي مجدد كافكا را به روشي سازگار با ساير سرويس هاي لينوكس انجام دهيد.
ZooKeeper سرويسي است كه كافكا براي مديريت وضعيت و تنظيمات خوشه اي از آن استفاده مي كند. معمولاً در سيستم هاي توزيع شده به عنوان يك جزء اساسي مورد استفاده قرار مي گيرد. در اين آموزش از Zookeeper براي مديريت اين جنبه هاي كافكا استفاده خواهيد كرد. اگر تمايل داريد اطلاعات بيشتري در مورد آن بدانيد ، به مطالب ZooKeeper رسمي ما مراجعه كنيد.
ابتدا فايل واحد را براي zookeeper ايجاد كنيد:
sudo nano /etc/systemd/system/zookeeper.service
تعريف واحد زير را در پرونده وارد كنيد:
/etc/systemd/system/zookeeper.service
[Unit]
Requires=network.target remote-fs.target
After=network.target remote-fs.target

[Service]
Type=simple
User=kafka
ExecStart=/home/kafka/kafka/bin/zookeeper-server-start.sh /home/kafka/kafka/config/zookeeper.properties
ExecStop=/home/kafka/kafka/bin/zookeeper-server-stop.sh
Restart=on-abnormal

[Install]
WantedBy=multi-user.target

بخش [Unit] مشخص مي كند كه ZooKeeper به شبكه نياز دارد و سيستم فايل قبل از شروع آن آماده است.
در بخش [Service] مشخص شده است كه systemd براي شروع و متوقف كردن سرويس بايد از پرونده هاي zookeeper-server-start.sh و zookeeper-server-stop.sh استفاده كند. همچنين مشخص مي كند در صورت خارج شدن غيرطبيعي ، ZooKeeper بايد به طور خودكار مجدداً راه اندازي شود.
در مرحله بعد، فايل سرويس systemd را براي kafka ايجاد كنيد:
sudo nano /etc/systemd/system/kafka.service

تعريف واحد زير را در پرونده وارد كنيد:
/etc/systemd/system/kafka.service
[Unit]
Requires=zookeeper.service
After=zookeeper.service

[Service]
Type=simple
User=kafka
ExecStart=/bin/sh -c ‘/home/kafka/kafka/bin/kafka-server-start.sh /home/kafka/kafka/config/server.properties > /home/kafka/kafka/kafka.log 2>&1’
ExecStop=/home/kafka/kafka/bin/kafka-server-stop.sh
Restart=on-abnormal

[Install]
WantedBy=multi-user.target

بخش [Unit] مشخص مي كند كه اين فايل واحد به zookeeper.service بستگي دارد. اين امر اطمينان مي دهد كه با شروع سرويس كافكا ، zookeeper به طور خودكار شروع مي شود.
در بخش [Service] مشخص شده است كه systemd بايد براي شروع و توقف سرويس از فايلهاي پوسته kafka-server-start.sh و kafka-server-stop.sh استفاده كند. همچنين مشخص مي كند در صورت خارج شدن غير عادي ، كافكا بايد به طور خودكار مجدداً راه اندازي شود.
اكنون كه واحدها تعريف شده اند ، كافكا را با دستور زير شروع كنيد:
sudo systemctl start kafka
براي اطمينان از شروع موفقيت آميز سرور ، گزارش هاي ژورنال را براي واحد kafka بررسي كنيد:
sudo journalctl -u kafka
خروجي مشابه موارد زير را مشاهده خواهيد كرد:
Mar 23 13:31:48 kafka systemd[1]: Started kafka.service.

اكنون يك سرور كافكا روي درگاه 9092 داريد كه درگاه پيش فرض براي كافكا است.
شما سرويس kafka را شروع كرده ايد ، اما اگر مي خواهيد سرور خود را دوباره راه اندازي كنيد ، هنوز به طور خودكار شروع نمي شود. براي فعال كردن kafka در بوت سرور ، اين سرور را اجرا كنيد:
sudo systemctl enable kafka
اكنون كه سرويس ها را شروع و فعال كرده ايد ، زمان آن رسيده است كه نصب را بررسي كنيد.
مرحله 5 – تست نصب
بياييد پيام Hello World را منتشر و استفاده كنيم تا مطمئن شويم كه سرور كافكا به درستي رفتار مي كند. انتشار پيام در كافكا به موارد زير بستگي دارد:
تهيه كننده، كه امكان انتشار سوابق و داده ها به عناوين را فراهم مي كند.
مصرف كننده، كه پيام ها و داده ها را از عناوين مي خواند.
ابتدا با تايپ كردن دستور زير عنواني به نام TutorialTopic ايجاد كنيد:
~/kafka/bin/kafka-topics.sh –create –zookeeper localhost:2181 –replication-factor 1 –partitions 1 –topic TutorialTopic
مي توانيد با استفاده از اسكريپت kafka-console-producer.sh يك تهيه كننده از خط فرمان ايجاد كنيد. اين تهيه كننده نام ميزبان ، پورت و نام عنوان سرور كافكا را به عنوان آرگومان ميشناسد.

رشته Hello, World را با تايپ كردن دستور زير براي عنوان TutorialTopic منتشر كنيد:
echo “Hello, World” | ~/kafka/bin/kafka-console-producer.sh –broker-list localhost:9092 –topic TutorialTopic > /dev/null
فلگ – broker-list ليست كارگزاران پيام براي ارسال پيام به آن ها كه در اين مورد localhost: 9092 است را تعيين مي كند. –topic موضوع را به عنوان TutorialTopic تعيين مي كند.
در مرحله بعد ، مي توانيد با استفاده از اسكريپت kafka-console-consumer.sh يك مصرف كننده كافكا ايجاد كنيد. انتظار مي رود نام ميزبان و پورت سرور ZooKeeper و نام تاپيك به عنوان آرگومان باشد.
دستور زير از پيام هاي TutorialTopic استفاده مي كند. توجه داشته باشيد كه از فلگ –from-beginning استفاده كنيد كه امكان استفاده از پيام هايي را كه قبل از شروع مصرف كننده منتشر شده است ، فراهم كند:
~/kafka/bin/kafka-console-consumer.sh –bootstrap-server `localhost:9092` –topic TutorialTopic –from-beginning
–bootstrap-server ليستي از ورودي ها به خوشه كافكا را ارائه مي دهد. در اين حالت ، از localhost استفاده مي كنيد: 9092.
Hello, World را در ترمينال خود مشاهده خواهيد كرد:
خروجي
Hello, World

اين اسكريپت همچنان اجرا مي شود و منتظر انتشار پيام هاي بيشتري براي موضوع خواهد بود. با خيال راحت يك ترمينال جديد باز كنيد و يك تهيه كننده راه اندازي كنيد تا چند پيام ديگر انتشار دهد. شما بايد همه آنها را در خروجي مصرف كننده ببينيد. اگر مي خواهيد در مورد نحوه استفاده از كافكا اطلاعات بيشتري كسب كنيد ، به اطلاعات موجود در لينك كافكا رسمي مراجعه كنيد.
وقتي آزمايش انجام شد ، CTRL + C را فشار دهيد تا اسكريپت مصرف كننده متوقف شود. اكنون كه نصب را آزمايش كرده ايد ، مي توانيد براي اجراي بهتر خوشه كافكا ، به نصب KafkaT برويد.
مرحله 6 – نصب KafkaT (اختياري)
KafkaT ابزاري از Airbnb است كه مشاهده جزئيات مربوط به خوشه كافكا و انجام برخي كارهاي اجرايي از خط فرمان را براي شما آسانتر مي كند. از آنجا كه اين يك Ruby gem است ، براي استفاده از آن به Ruby نياز خواهيد داشت. براي ساختن ساير gemها كه به آن بستگي دارد ، به بسته build-essential نيز احتياج خواهيد داشت. آنها را با استفاده از apt نصب كنيد:
sudo apt install ruby ruby-dev build-essential
اكنون مي توانيد KafkaT را با استفاده از دستور gem نصب كنيد:
sudo CFLAGS=-Wno-error=format-overflow gem install kafkat
گزينه CFLAGS = -Wno-error = format-overflow هشدارهاي فرمت بيش از حد را غيرفعال مي كند و براي gem ZooKeeper ، كه وابسته به KafkaT است ، لازم ميباشد.

KafkaT از .kafkatcfg به عنوان فايل پيكربندي براي تعيين نصب و ورود به فهرست سرورهاي كافكا استفاده مي كند. همچنين بايد داراي ورودي باشد كه KafkaT را به عنوان مثال ZooKeeper به شما نشان دهد.
يك فايل جديد با نام .kafkatcfg ايجاد كنيد:
nano ~/.kafkatcfg
خطوط زير را اضافه كنيد تا اطلاعات لازم در مورد سرور كافكا و مثال Zookeeper خود را مشخص كنيد:
~/.kafkatcfg
{
“kafka_path”: “~/kafka”,
“log_path”: “/tmp/kafka-logs”,
“zk_path”: “localhost:2181”
}

اكنون آماده استفاده از كافكا هستيد. براي شروع ، در اينجا نحوه استفاده از آن براي مشاهده جزئيات مربوط به همه پارتيشن هاي كافكا آورده شده است:
kafkat partitions
خروجي زير را مشاهده خواهيد كرد:
Output
Topic Partition Leader Replicas ISRs
TutorialTopic 0 0 [0] [0]
__consumer_offsets 0 0 [0] [0]

اين خروجي TutorialTopic و همچنين __consumer_offsets يك عنوان داخلي كه توسط كافكا براي ذخيره اطلاعات مربوط به مشتري استفاده مي شود ، نشان مي دهد. با خيال راحت مي توانيد خطوط شروع شده با __consumer_offsets را ناديده بگيريد.
براي كسب اطلاعات بيشتر در مورد KafkaT ، به منبع GitHub آن مراجعه كنيد.
اكنون كه KafkaT را نصب كرديد ، مي توانيد Kafka را به صورت اختياري بر روي خوشه اي از سرورهاي Debian 10 تنظيم كنيد تا يك خوشه چند گره ايجاد شود.
مرحله 7 – تنظيم يك خوشه چند گره (اختياري)
اگر مي خواهيد با استفاده از سرورهاي Debian 10 بيشتر ، يك خوشه چند كاره ايجاد كنيد، مرحله 1 ، مرحله 4 و مرحله 5 را روي هر يك از ماشين هاي جديد تكرار كنيد. علاوه بر اين، براي پرونده هاي ~ / kafka / config / server.properties تغييرات زير را انجام دهيد:

مقدار ويژگي broker.id را طوري تغيير دهيد كه در كل خوشه بي نظير باشد. اين ويژگي به طور منحصر به فرد هر سرور موجود در خوشه را مشخص مي كند و مي تواند هر رشته اي را به عنوان مقدار آن داشته باشد. به عنوان مثال ، “server1” ، “server2” و غيره ، به عنوان شناساگر مفيد خواهند بود.
مقدار ويژگي zookeeper.connect را به گونه اي تغيير دهيد كه همه گره ها به همان مثال ZooKeeper اشاره كنند. اين ويژگي آدرس نمونه ZooKeeper را مشخص مي كند و از قالب : پيروي مي كند. براي اين آموزش ، شما از your_first_server_IP: 2181 استفاده خواهيد كرد و your_first_server_IP را با آدرس IP سرور Debian 10 كه قبلاً تنظيم كرده ايد جايگزين كنيد.
اگر مي خواهيد چندين نمونه ZooKeeper براي خوشه خود داشته باشيد ، مقدار ويژگي zookeeper.connect در هر گره بايد يك رشته يكسان با كاما باشد كه در آن آدرس هاي IP و شماره پورت همه موارد ZooKeeper را نشان مي دهد.
توجه: اگر يك فايروال داريد كه روي سرور Debian 10 با نصب Zookeeper فعال شده است ، حتما پورت 2181 را باز كنيد تا اجازه ورود از ساير گره هاي خوشه را دريافت كنيد.
مرحله 8 – محدود كردن كاربر كافكا
اكنون كه تمام مراحل نصب انجام شده است ، مي توانيد امتيازات ادمين كاربر kafka را حذف كنيد. قبل از انجام اين كار ، مانند هر كاربر سودو غير ريشه خارج شويد و دوباره وارد سيستم شويد. اگر هنوز همان بخش شل را اجرا مي كنيد كه اين آموزش را با آن شروع كرده ايد ، فقط exit تايپ كنيد.
كاربر كافكا را از گروه سودو حذف كنيد:
sudo deluser kafka sudo
براي بهبود بيشتر امنيت سرور كافكا ، رمزعبور كاربر kafka را با استفاده از دستور passwd قفل كنيد. اين اطمينان مي دهد كه هيچ كس نمي تواند با استفاده از اين حساب به طور مستقيم وارد سرور شود:
sudo passwd kafka -l
در اين مرحله فقط كاربر root يا يك كاربر sudo مي توانند با وارد كردن دستور زير به عنوان kafka وارد شوند:
sudo su – kafka
در آينده اگر مي خواهيد قفل آن را باز كنيد ، از passwd با گزينه -u استفاده كنيد:
sudo passwd kafka -u
شما اكنون با موفقيت امتيازات ادمين كاربري kafka را محدود كرده ايد.
نتيجه
اكنون Apache Kafka به طور ايمن روي سرور Debian شما اجرا شده است. شما مي توانيد با ايجاد تهيه كنندگان و مصرف كنندگان از بين مشتري هاي كافكا ، كه براي اكثر زبان هاي برنامه نويسي در دسترس است، از آن در پروژه هاي خود استفاده كنيد. براي كسب اطلاعات بيشتر در مورد كافكا، همچنين مي توانيد با آپاچي كافكا مشورت كنيد.


برچسب: ،
بازدید:

ادامه مطلب

نوشته شده: ۸ بهمن ۱۳۹۸ساعت: ۰۱:۲۴:۵۲ توسط:server موضوع:
موضوعات
    موضوعي ثبت نشده است
پنل کاربری
نام کاربری :
پسورد :
آمار
امروز : 1
دیروز : 0
افراد آنلاین : 1
همه : 10
پنل کاربری
نام کاربری :
پسورد :
تکرار پسورد:
ایمیل :
نام اصلی :

http://www.monoblog.ir/ads/fb4a1af661a1397ded95f0fe7a798f6b.gif

لینک های روزانه
لينكي ثبت نشده است
لینک های تبادلی
فاقد لینک
تبادل لینک اتوماتیک
لینک :
خبرنامه
عضویت لغو عضویت
چت باکس
صفحات
[ ۱ ]