در این مطلب ایجاد یک محیط ایمیل سرور با داکر[1] را به شما آموزش می‌دهیم که سنگ بنای سایر مقالات موجود در زمینه پیاده‌سازی‌های ابر بومی است.
مقدمه‌ای بر ایجاد یک ایمیل سرور با داکر
زمانی که قصد اجرای کدها روی سرورهای مختلف را دارید، می‌توانید کد و کلیه الزامات مورد نیاز برای اجرای آن را در یک واحد نرم‌افزاری بنام کانتینر (container) قرار دهید. بنابراین امکان اجرای کد، مستقل از نوع پیکربندی سیستم وجود دارد. مدیریت کانتینرها بر عهده ابزار متن باز کوبرنیتز است.
هدف اصلی این مطلب گردآوری گام‌هایی است که کاربر باید برای نصب نرم‌افزار ایمیل سرور داکری، بر روی یک کلاستر کوبرنتیز طی کند. می‌توانید این مقاله را به عنوان مرجع در نظر بگیرید و هر زمان نیاز به یادآوری نکته‌ای درباره نصب نرم‌افزار ایمیل سرور با داکر و کوبرنتیز داشتید از آن استفاده کنید.
در این مطلب مراحل تبدیل RPM[2] یا Redhat Package Manager به یک ایمیل داکر، انتشار روی یک داکر هاب[3]، ایجاد و تنظیم کلاستر در پلتفرم ابر گوگل و نصب ایمیج خودمان را به شما توضیح می‌دهیم.
برنامه کاربردی نمونه: ایمیل سرور Axigen
در این مطلب از ایمیل سرور داکر Axigen به عنوان برنامه کاربردی نمونه استفاده می‌کنیم چون با اینکه مخصوص فناوری ایمیل سرور است اما بسیاری از الزامات برنامه‌های کاربردی مدرن را برآورده می‌کند. تعدادی از این الزامات شامل موارد زیر هستند:
- یک بخش فرانت -اند که درخواست‌های کاربر در آن دریافت می‌شود؛
- یک بخش بک -اند که وضعیت را ذخیره می‌کند.
- یک بخش ایستا که یک رابط کاربری زیبا به کاربران نمایش داده و آنها را به فرانت -اند متصل می‌کند.
بنابراین می‌توان این آزمایش را برای سایر برنامه‌های کاربردی هم اجرا کرد.
توجه: Axigen یک ایمیج داکر کاملاً کاربردی و آماده استفاده در داکر هاب ایجاد می‌کند. می‌توانید همه اطلاعات مربوط به پیاده سازی و اجرای Axigen در داکر را پیدا کرده و خودتان آن را امتحان کنید.
چرا از ایمیل سرور ابر بومی استفاده کنیم؟
در ادامه مزایای تبدیل ایمیل سرور به یک نرم‌افزار ابر بومی مخزنی را مورد بررسی قرار می‌دهیم:
-
کاهش وابستگی به سیستم‌عامل مبنا (که مخزن را اجرا می‌کند)
- می‌توان مخزن را به راحتی و بدون بسته‌بندی مجدد (repackaging) جابجا کرد؛
- نیاز به کنترل سیستم‌عامل پایه را از نظر نظارت، ارتقای نرم‌افزارها و غیره از بین می‌برد (برخلاف مدل Rehost که در آن مشتری همچنان باید ایمیج سیستم‌عامل تأمین شده توسط ارائه‌دهنده ابر را مدیریت کند)؛
- استقلال از ارائه‌دهنده (نیازی به نصب مجدد برنامه‌های کاربردی و مهاجرت داده‌ها در هنگام تغییر ارائه دهنده وجود ندارد).
-
ساده‌سازی چشمگیر افزایش مقیاس
- در محیط مجازی، افزایش مقیاس عمودی (اضافه کردن ظرفیت دیسک، حافظه و پردازنده) کار راحتی است اما مقیاس پذیری افقی[4] محدودتر است؛
- رویکرد مخزن محور باعث می‌شود که توسعه دهنده/ پکیج کننده برنامه کاربردی دیدگاه «ابر بومی» پیدا کند در نتیجه مسائل رایانشی را از مسائل مربوط به ذخیره اطلاعات و خود مدل تفکیک می‌کند؛
- به دلیل کاهش چشمگیر سربار مدل مخزنی نسبت به ماشین مجازی، تعداد نمونه‌ها از ده‌ها به هزاران عدد قابل افزایش است در نتیجه بار مدیریت سطح بالای همروندی توسط نرم‌افزار کاهش پیدا می‌کند.
مدل سرور ابر بومی بیشتر مناسب چه افرادی است؟
با توجه به تعداد زیاد پلتفرم‌های موجود (مثل AWS، آژور، آی‌بی‌ام کلود و غیره) که ماشین‌های ابری را در اختیار شما قرار می‌دهند و می‌توانید محصولات را به راحتیِ مدل درون سازمانی روی آنها نصب و مدیریت کنید، استفاده از این امکانات منطقی‌ترین گزینه است.
اما از آنجایی که پیاده سازی مدل ابر بومی نیاز به تحقیق و آموزش زیادی دارد و مزایای آن بیشتر در آینده مشخص می‌شوند، بهتر است کاربرانی که مزایای این مدل برای آنها بیشتر است، از آن استفاده کنند مثل:
- توسعه دهندگان نرم‌افزار که می‌توانند مزایای مدل ابر بومی را در اختیار مشتریانشان قرار دهند؛
- شرکت‌های متوسط تا بزرگی که منابع مورد نیاز برای سرمایه گذاری اولیه را در اختیار دارند؛
- ارائه دهندگان سرویس که برای آنها کاهش هزینه‌های نگهداری و مقیاس پذیری مهم‌ترین فاکتورهای تجاری هستند.
رویکرد ابر بومی – تغییر پلتفرم
تا اینجا درباره روش تغییر میزبان یا مجازی سازی یک ماشین فیزیکی و انتقال آن به بستر ابر – یا انتقال ماشین‌های مجازی درون سازمانی، به یک سرویس ابر – صحبت کردیم. در ادامه شیوه «ابر بومی کردن» با روش تغییر پلتفرم را مورد بررسی قرار می‌دهیم.
ایجاد یک محیط ایمیل سرور با داکر
ساده‌ترین روش برای رسیدن به یک ایمیج داکری بر اساس یک نرم‌افزار پکیج شده به روش سنتی (RPM, DEB) به شرح زیر است.
از آنجا که قرار است این برنامه کاربردی در کوبرنتیز اجرا شود، ابتدا باید آن را داکری کنیم تا امکان اجرای آن روی کوبرنیتز فراهم شود.
می‌توانید از سایر ارائه‌دهندگان نرم‌افزار مخزن استفاده کنید اما داکر در این زمینه پیشگام است و درصد بسیاری از سهم بازار را در اختیار دارد.
به عنوان پکیج استاندارد برای شروع این کار، از توزیع RPM استفاده شده اما این کار را با ابزاری که خودمان بیشتر از آن استفاده می‌کنیم انجام دادیم (یعنی دبیان/اوبونتو).
ایجاد ایمیج داکر کاملاً مشابه نصب یک پکیج روی یک سیستم‌عامل واقعی است. فرض شده که مخاطب با کلیات استفاده از خط فرمان آشنا بوده و داکر را نصب کرده است. همانطور که گفته شد هدف ما ارائه مثالی از به دست آوردن یک مخزن (container) از یک ایمیج CentOS است.
توجه: به تفاوت بین ایمیج و نمونه دقت داشته باشید (از اصطلاح «نمونه» برای این استفاده می‌کنیم تا آن را از خود مفهوم مخزن تفکیک کنیم).
نمونه (یا مخزن) معادل با یک ماشین است؛ هر نمونه یک آی‌پی دارد، می‌تواند فرمان‌ها را روی یک پوسته درون خودش اجرا کند و غیره. ایمیج، معادل پکیج است؛ همیشه می‌توانید از یک ایمیج برای ایجاد یک نمونه (یا مخزن) استفاده کنید.
-
ایجاد یک نمونه داکر CentOS
ایجاد این نمونه داکر از ایمیج CentOS را شروع می‌کنیم:
ion@IN-MBP ~ % docker run -it centos:latest
[root@7294b716163d /]#
می‌توانیم از یک ترمینال دیگر، نمونه ایجاد شده را مشاهده کنیم:
ion@IN-MBP ~ % docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7294b716163d centos:latest “/bin/bash” 20 seconds ago Up 20 seconds zen_austin
همانطور که هر نمونه سیستم‌عامل معمولی را به روزرسانی می‌کنیم، حالا سیستم‌عامل را به روزرسانی می‌کنیم:
[root@7294b716163d /]# dnf -y update
Failed to set locale, defaulting to C.UTF-8
CentOS-8 – AppStream 4.6 MB/s | 7.0 MB 00:01
CentOS-8 – Base 2.0 MB/s | 2.2 MB 00:01
CentOS-8 – Extras 9.7 kB/s | 5.9 kB 00:00
Dependencies resolved.
================================================================================================================================================================================================================================================
Package Architecture Version Repository Size
================================================================================================================================================================================================================================================
Upgrading:
audit-libs x86_64 3.0-0.13.20190507gitf58ec40.el8 BaseOS 116 k
binutils x86_64 2.30-58.el8_1.2 BaseOS 5.7 M
centos-gpg-keys noarch 8.1-1.1911.0.9.el8 BaseOS 12 k
centos-release x86_64 8.1-1.1911.0.9.el8 BaseOS 21 k
centos-repos x86_64 8.1-1.1911.0.9.el8 BaseOS 13 k
coreutils-single x86_64 8.30-6.el8_1.1 BaseOS 630 k
glibc x86_64 2.28-72.el8_1.1 BaseOS 3.7 M
glibc-common x86_64 2.28-72.el8_1.1 BaseOS 836 k
glibc-minimal-langpack x86_64 2.28-72.el8_1.1 BaseOS 48 k
kexec-tools x86_64 2.0.19-12.el8_1.2 BaseOS 482 k
libarchive x86_64 3.3.2-8.el8_1 BaseOS 359 k
openldap x86_64 2.4.46-11.el8_1 BaseOS 352 k
openssl-libs x86_64 1:1.1.1c-2.el8_1.1 BaseOS 1.5 M
python3-rpm x86_64 4.14.2-26.el8_1 BaseOS 156 k
rpm x86_64 4.14.2-26.el8_1 BaseOS 539 k
rpm-build-libs x86_64 4.14.2-26.el8_1 BaseOS 153 k
rpm-libs x86_64 4.14.2-26.el8_1 BaseOS 336 k
sqlite-libs x86_64 3.26.0-4.el8_1 BaseOS 579 k
systemd x86_64 239-18.el8_1.5 BaseOS 3.5 M
systemd-libs x86_64 239-18.el8_1.5 BaseOS 562 k
systemd-pam x86_64 239-18.el8_1.5 BaseOS 232 k
systemd-udev x86_64 239-18.el8_1.5 BaseOS 1.3 M
Installing dependencies:
xkeyboard-config noarch 2.24-3.el8 AppStream 828 k
kbd-legacy noarch 2.0.4-8.el8 BaseOS 481 k
kbd-misc noarch 2.0.4-8.el8 BaseOS 1.4 M
openssl x86_64 1:1.1.1c-2.el8_1.1 BaseOS 686 k
Installing weak dependencies:
libxkbcommon x86_64 0.8.2-1.el8 AppStream 116 k
diffutils x86_64 3.6-5.el8 BaseOS 359 k
glibc-langpack-en x86_64 2.28-72.el8_1.1 BaseOS 818 k
kbd x86_64 2.0.4-8.el8 BaseOS 392 k
openssl-pkcs11 x86_64 0.4.8-2.el8 BaseOS 64 k
Transaction Summary
================================================================================================================================================================================================================================================
Install 9 Packages
Upgrade 22 Packages
[………………………………]
Upgraded:
audit-libs-3.0-0.13.20190507gitf58ec40.el8.x86_64 binutils-2.30-58.el8_1.2.x86_64 centos-gpg-keys-8.1-1.1911.0.9.el8.noarch centos-release-8.1-1.1911.0.9.el8.x86_64 centos-repos-8.1-1.1911.0.9.el8.x86_64
coreutils-single-8.30-6.el8_1.1.x86_64 glibc-2.28-72.el8_1.1.x86_64 glibc-common-2.28-72.el8_1.1.x86_64 glibc-minimal-langpack-2.28-72.el8_1.1.x86_64 kexec-tools-2.0.19-12.el8_1.2.x86_64
libarchive-3.3.2-8.el8_1.x86_64 openldap-2.4.46-11.el8_1.x86_64 openssl-libs-1:1.1.1c-2.el8_1.1.x86_64 python3-rpm-4.14.2-26.el8_1.x86_64 rpm-4.14.2-26.el8_1.x86_64
rpm-build-libs-4.14.2-26.el8_1.x86_64 rpm-libs-4.14.2-26.el8_1.x86_64 sqlite-libs-3.26.0-4.el8_1.x86_64 systemd-239-18.el8_1.5.x86_64 systemd-libs-239-18.el8_1.5.x86_64
systemd-pam-239-18.el8_1.5.x86_64 systemd-udev-239-18.el8_1.5.x86_64
Installed:
libxkbcommon-0.8.2-1.el8.x86_64 diffutils-3.6-5.el8.x86_64 glibc-langpack-en-2.28-72.el8_1.1.x86_64 kbd-2.0.4-8.el8.x86_64 openssl-pkcs11-0.4.8-2.el8.x86_64 xkeyboard-config-2.24-3.el8.noarch kbd-legacy-2.0.4-8.el8.noarch
kbd-misc-2.0.4-8.el8.noarch openssl-1:1.1.1c-2.el8_1.1.x86_64
Complete!
حالا سیستم‌عامل به روز شد.
-
نصب Axigen در نمونه مخزن
اول RPM را دریافت می‌کنیم:
ion@IN-MBP ~ % docker exec -it 7294b716163d bash
[root@7294b716163d app]# curl -O https://www.axigen.com/usr/files/axigen-10.3.1/axigen-10.3.1.x86_64.rpm.run
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 386M 100 386M 0 0 9.7M 0 0:00:39 0:00:39 –:–:– 9.8M
سپس آن را نصب می‌کنیم:
root@7294b716163d /]# ./axigen-10.3.1.x86_64.rpm.run
Please accept the terms of the license before continuing
Press ENTER to display the license
(after reading it press ‘q’ to exit viewer)
q
Do you accept the terms of the license? (yes/no): y
======================================
RPM Package for x86_64 Installer for AXIGEN Mail Server 10.3.1-1
======================================
Detecting OS flavor… CentOS 8.1
Installer started
Axigen embedded archive extracted successfully
Please select one of the options displayed below:
==== Main options
1. Install axigen-10.3.1-1
9. Exit installer
0. Exit installer without deleting temporary directory
===== Documentation for axigen-10.3.1-1
4. Show the RELEASE NOTES
5. Show the README file
6. Show other licenses included in the package
7. Show manual install instructions
8. Show manual uninstall instructions
Your choice: 1
Verifying… ################################# [100%]
Preparing… ################################# [100%]
Updating / installing…
1:axigen-10.3.1-1 ################################# [100%]
Thank you for installing AXIGEN Mail Server.
In order to configure AXIGEN for the first time, please connect
to WebAdmin by using one of the URLs below:
https://172.17.0.2:9443/
https://[2a02:2f0b:a20c:a500:0:242:ac11:2]:9443/
Starting AXIGEN Mail Server…Axigen[336]: INFO: Starting Axigen Mail Server version 10.3.1.5 (Linux/x64)
Axigen[336]: SUCCESS: supervise ready… (respawns per minute: 3)
Axigen[336]: INFO: supervise: spawning a new process to execute Axigen Mail Server version 10.3.1.5 (Linux/x64)
[ OK ]
Installer finished.
حالا Axigen را در مخزن نصب کردیم و حتی اجرای آن شروع شده است (نصب کننده، آن را به صورت خودکار اجرا می‌کند)»
[root@7294b716163d /]# ps ax | grep axigen
336 ? Ss 0:00 /opt/axigen/bin/axigen –max-respawns 3 -W /var/opt/axigen
337 ? SNl 0:01 /opt/axigen/bin/axigen –max-respawns 3 -W /var/opt/axigen
351 ? Sl 0:00 axigen-tnef
375 pts/0 S+ 0:00 grep –color=auto axigen
امتحان می‌کنیم که وقتی پوسته را ترک کنیم، چه می‌شود:
[root@7294b716163d /]# exit
exit
ion@IN-MBP ~ %
آیا نمونه ما همچنان در حال اجرا است؟
ion@IN-MBP ~ % docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ion@IN-MBP ~ %
خیر، به دلیل اینکه ایمیج CentOS bash را به عنوان پردازش اصلی مخزن اجرا می‌کند؛ زمانی که از bash خارج شویم، اجرای مخزن هم متوقف می‌شود.
نکته مهم: مخزن یک پردازش دارد که آن را به عنوان پردازش اصلی در نظر می‌گیرد؛ زمانی که این پردازش متوقف شود، مخزن هم متوقف خواهد شد.
ماهیت اجرای آزمایش همین است یعنی امتحان روش‌های مختلف رسیدن به نتیجه و بررسی اینکه کدام روش ما را به هدف می‌رساند.
این یکی از تفاوت‌های مهم بین مخزن و یک میزبان لینوکس سنتی است – هیچ دیمنی (daemon) وجود ندارد – به عبارت دیگر، نیازی به انشعاب در پس زمینه وجود ندارد (به این دلیل که معمولاً برای نرم‌افزارهایی که به سبک SystemV – و همچنین Systemd – شروع می‌شوند، اسکریپت‌های init هم کار می‌کند).
می‌توانیم هنگام ایجاد ایمیج Axigen از این نکته استفاده کنیم. باز هم کار را با مخزن شروع می‌کنیم:
ion@IN-MBP ~ % docker start 7294b716163d
7294b716163d
و بررسی می‌کنیم که آیا در حال اجرا است:
ion@IN-MBP ~ % docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
7294b716163d centos:latest “/bin/bash” 13 minutes ago Up 41 seconds zen_austin
به آن متصل شده و بررسی می‌کنیم که آیا Axigen همچنان در حال اجرا است:
ion@IN-MBP ~ % docker attach 7294b716163d
[root@7294b716163d /]# ps ax
PID TTY STAT TIME COMMAND
1 pts/0 Ss 0:00 /bin/bash
14 pts/0 R+ 0:00 ps ax
اینطور نیست و نباید از این موضوع تعجب کرد: پردازش Axigen (و همه پردازش‌های فرعی منشعب شده از آن و ریسمان‌های شروع شده توسط آن) به همراه bash اصلی (پدربزرگ همه) متوقف می‌شوند.
در هر صورت، همچنان Axigen نصب شده است:
[root@7294b716163d /]# ls -la /var/opt/axigen/
total 288
drwxr-xr-x 16 axigen axigen 4096 May 25 15:07 .
drwxr-xr-x 1 root root 4096 May 25 15:07 ..
-rw-r—– 1 axigen axigen 2969 May 25 15:07 axigen_cert.pem
-rw-r—– 1 axigen axigen 245 May 25 15:07 axigen_dh.pem
drwxr-xr-x 2 axigen axigen 4096 May 25 15:07 aximigrator
-rw——- 1 axigen axigen 215556 Feb 7 12:57 cacert_default.pem
drwxr-x–x 2 axigen axigen 4096 May 25 15:07 cyren
drwx–x— 2 axigen axigen 4096 May 25 15:07 filters
drwx–x— 3 axigen axigen 4096 May 25 15:07 kas
drwx–x— 4 axigen axigen 4096 May 25 15:07 kav
drwx—— 2 axigen axigen 4096 May 25 15:07 letsencrypt
drwxr-x— 2 axigen axigen 4096 May 25 15:07 log
-rw——- 1 axigen axigen 121 Feb 7 12:57 mobile_ua.cfg
drwxr-x— 67 axigen axigen 4096 May 25 15:07 queue
drwxr-x— 2 axigen axigen 4096 May 25 15:07 reporting
drwxr-x— 2 axigen axigen 4096 May 25 15:07 run
drwxr-x— 2 axigen axigen 4096 May 25 15:07 serverData
drwx–x— 5 axigen axigen 4096 May 25 15:07 templates
drwx–x— 8 axigen axigen 4096 May 25 15:07 webadmin
drwx–x— 3 axigen axigen 4096 May 25 15:07 webmail
[root@7294b716163d /]# ls -la /opt/axigen/bin/
total 135028
drwxr-x–x 2 root root 4096 May 25 15:07 .
drwxr-x–x 5 root root 4096 May 25 15:07 ..
-rwxr-xr-x 1 root root 81771736 Feb 7 12:57 axigen
-rwxr-xr-x 1 root root 12824731 Feb 7 12:57 axigen-migrator
-rwxr-xr-x 1 root root 11838532 Feb 7 12:57 axigen-tnef
-rwxr-xr-x 1 root root 1049336 Feb 7 12:57 cyren.bin
-rwxr-xr-x 1 root root 205632 Feb 7 12:58 kasserver
-rwxr-xr-x 1 root root 180992 Feb 7 12:58 kavserver
-rwxr-xr-x 1 root root 663136 Feb 7 12:57 mqview
-rwxr-xr-x 1 root root 29704280 Feb 7 12:57 sendmail
حالا Axigen نصب شده اما هدف ما، ایمیج بود نه مخزن.
-
ایجاد ایمیج از یک مخزن
با خروج از پوسته، مخزن را متوقف می‌کنیم:
[root@7294b716163d /]# exit
ion@IN-MBP ~ % docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ion@IN-MBP ~ %
و بعد از جادوی داکر استفاده می‌کنیم!
ion@IN-MBP ~ % docker commit 7294b716163d my_new_and_shiny_axigen_image
sha256:e7ca09e1933bff546d7acbd7090543e2a4f886ee3aa60b7cbf04eefd70fcbe3b
ما از روی مخزن فعلی یک ایمیج جدید (my_new_and_shiny_axigen_image) ایجاد کردیم و حالا می‌توانیم از آن برای ایجاد یک مخزن دیگر استفاده کنیم که به روزرسانی‌های سیستم عامل به آن اعمال شده و Axigen در آن نصب شده است:
ion@IN-MBP ~ % docker run -it my_new_and_shiny_axigen_image
[root@479421167f8d /]# dnf update
Last metadata expiration check: 1:01:28 ago on Mon 25 May 2020 03:03:43 PM UTC.
Dependencies resolved.
Nothing to do.
Complete!
[root@479421167f8d /]# rpm -qa | grep axigen
axigen-10.3.1-1.x86_64
هنوز باید مخزن را پیکربندی کنیم تا باینری Axigen هنگام نمونه سازی شروع به کار کند. ایمیج ایجاد شده، نقطه ورود ایمیج CentOS را که bash است، به ارث برده و می‌توانیم آن را شروع کنیم:
[root@479421167f8d /]# /etc/init.d/axigen start
Starting AXIGEN Mail Server…Axigen[29]: INFO: Starting Axigen Mail Server version 10.3.1.5 (Linux/x64)
Axigen[29]: SUCCESS: supervise ready… (respawns per minute: 3)
Axigen[29]: INFO: supervise: spawning a new process to execute Axigen Mail Server version 10.3.1.5 (Linux/x64)
[ OK ]
[root@479421167f8d /]#
[root@479421167f8d /]# ps ax | grep axigen
29 ? Ss 0:00 /opt/axigen/bin/axigen –max-respawns 3 -W /var/opt/axigen
30 ? Sl 0:00 /opt/axigen/bin/axigen –max-respawns 3 -W /var/opt/axigen
42 ? Sl 0:00 axigen-tnef
66 pts/0 S+ 0:00 grep –color=auto axigen
اما این روش برای اجرای یک برنامه کاربردی توسط یک مخزن روش مناسبی نیست. روش درست، پیکربندی باینری است که هنگام شروع به کار مخزن، به صورت مستقیم روی ایمیج از آن استفاده می‌شود.
-
تنظیم نقطه ورود در مخزن
برای انجام این کار، باید دوباره به مرحله ایجاد ایمیج برگردیم:
ion@IN-MBP ~ % docker commit -c ‘CMD [“/opt/axigen/bin/axigen”, “–foreground”]’ 7294b716163d my_2nd_new_and_shiny_axigen_image
sha256:ef7ce0fd9a47acb4703e262c4eb64c3564a54866b125413c17a63c1f832d1443
ion@IN-MBP ~ %
در پیکربندی ایمیج، نام فرمان و آرگومان‌هایی که هنگام شروع مخزن اجرا می‌شوند را اضافه می‌کنیم:
/opt/axigen/bin/axigen –foreground
دقت داشته باشید که نباید پردازش اصلی مخزن در پس زمینه منشعب شود؛ این پردازش باید به اجرا ادامه دهد در غیر اینصورت مخزن متوقف می‌شود. به همین دلیل باید از آرگومان –foreground استفاده کنیم.
مثل Axigen، بیشتر سرورهای لینوکس یک آرگومان مخصوص دارند که به آنها دستور می‌دهد به جای انشعاب در پس زمینه، در پیش زمینه اجرا شوند.
-
اجرای ایمیج ساخته شده
ایمیج به روزرسانی شده را بررسی می‌کنیم:
ion@IN-MBP ~ % docker run -dt my_2nd_new_and_shiny_axigen_image
fd1b608174c402787152f5934294f370dfdb4d9b0f0b25e4edf4725dbe4c5700
ion@IN-MBP ~ %
ما پارامتر -it برای docker run را به -dt تغییر دادیم؛ بدون پرداختن به جزئیات بیشتر، کافیست در جریان باشید که این پارامتر به داکر دستور می‌دهد که از پردازش جدا شود. Axigen پردازش اصلی است در نتیجه استفاده از حالت تعاملی در اینجا به اندازه زمان استفاده از پوسته bash منطقی نیست.
با داکر می‌توانیم یک پردازش دیگر (نه پردازش اصلی بلکه پردازش ثانویه) را با استفاده از exec اجرا کنیم. ما یک bash را در حالت تعاملی اجرا می‌کنیم تا بتوانیم آنچه در مخزن رخ می‌دهد را بررسی کنیم.
ion@IN-MBP ~ % docker exec -it fd1b608174c4 bash
[root@fd1b608174c4 /]# ps ax
PID TTY STAT TIME COMMAND
1 pts/0 Ss+ 0:00 /opt/axigen/bin/axigen –foreground
7 pts/0 SNl+ 0:00 /opt/axigen/bin/axigen –foreground
19 pts/0 Sl+ 0:00 axigen-tnef
39 pts/1 Ss 0:00 bash
54 pts/1 R+ 0:00 ps ax
حالا Axigen در حال اجرا است اما آیا رابط کاربری وب ادمین (پورت 9000) هم در حال اجرا است؟
[root@fd1b608174c4 /]# telnet localhost 9000
Trying ::1…
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
GET / HTTP/1.1
Host: localhost
HTTP/1.1 303 Moved Temporarily
Server: Axigen-Webadmin
Location: /install
Connection: Close
همینطور است و ما به جریان تنظیم اولیه (/install) هدایت می‌شویم.
آیا پورت وب ادمین 9000 از خارج از مخزن هم در دسترس است؟
ion@IN-MBP ~ % telnet localhost 9000
Trying ::1…
Connection failed: Connection refused
Trying 127.0.0.1…
telnet: Unable to connect to remote host: Connection refused
باید هنگام نصب به مخزن اعلام کنیم که پورت 9000 را به میزبان نگاشت کند تا امکان دسترسی به آن از بیرون فراهم شود.
ion@IN-MBP ~ % docker run -dt -p 9000:9000 my_2nd_new_and_shiny_axigen_image
1dcc95e912bafc97ba63484abfeb7e2d1983d524b8834a5ccc62928796259818
ion@IN-MBP ~ %
به پارامتر -p 9000:9000 توجه کنید. این پارامتر به داکر اعلام می‌کند که پورت 9000 مخزن را در میزبان هم با همین شماره در دسترس قرار دهد و حالا…
ion@IN-MBP ~ % telnet localhost 9000
Trying ::1…
Connected to localhost.
Escape character is ‘^]’.
GET / HTTP/1.1
Host: localhost
HTTP/1.1 303 Moved Temporarily
Server: Axigen-Webadmin
Location: /install
Connection: Close
جمع‌بندی
این آزمایش کوچک چه درس‌هایی به ما داد؟
- تبدیل یک پکیج RPM / DEB موجود به یک ایمیج مخزن کار راحتی است:
- مخزن را با سیستم‌عامل دلخواهتان که پکیج نرم‌افزاری هدف را برای آن دارید، تنظیم کنید؛
- از طریق مخزن، نرم‌افزار را نصب کنید (و در صورت تمایل، پیکربندی‌های دلخواه را انجام دهید)؛
- مخزن را متوقف کرده و آن را به یک ایمیج تبدیل کنید و حتماً نقاط ورود مناسب را برای آن تنظیم کنید (CMD)؛
- مخازن دلخواه را با استفاده از ایمیج جدید ایجاد کنید؛
- ایمیج را منتشر کنید و در صورت نیاز در اختیار دیگران هم قرار دهید.
- ایمیج ایجاد شده برای مقاصد تولیدی آماده نیست و برای آماده کردن آن باید این کارها را انجام دهید:
- محل ذخیره پایدار را پیاده‌سازی کنید (ما از یک سرویس ایمیل استفاده می‌کنیم که پیام‌ها را ذخیره می‌کند در نتیجه بعضی از اطلاعات باید پایدار باشند)؛
- تعاریف لازم برای ارتباطات شبکه را ایجاد کنید:
- در حالت پیش فرض داکر از طریق NAT به پردازش‌ها امکان می‌دهد که با بیرون در تماس باشند (ارتباط را شروع کنند)؛
- اما باید بتوانیم ارتباطات ورودی (دسترسی‌های کلاینت، مسیریابی ایمیل‌ها) را روی پورت‌های خاصی دریافت کنیم؛
- گزینه‌های لازم برای تنظیم اولیه Axigen هنگام شروع به کار را مشخص کنید (ممکن است بخواهیم آن را با استفاده از یک مجوز خاص نصب کنیم).
حالا که ایمیج اصلی آماده شد، باید به مشکلاتی که قبلاً ذکر شد بپردازیم و ایجاد ایمیج را اتوماسیون کنیم (وقتی یک نسخه جدید از ایمیج CentOS یا یک پکیج Axigen جدید موجود باشد، چه می‌شود؟).
این موضوعات فراتر از حوزه این مقاله هستند اما نکات زیر می‌توانند مفید باشند:
- به جای نمونه‌سازی پایه و سپس نصب دستی نرم‌افزار Axigen، از Dockerfile برای ساختن ایمیج استفاده کنید؛
- در Dockerfile، دستورالعمل‌های CMD، ENV، EXPOSE و VOLUME لازم را تعریف کرده و نگاشت کنید.
- برای به اشتراک گذاشتن ایمیج با دیگران از طریق یک رجیستری داکر (مخزن ایمیج) خصوصی یا عمومی از دستورالعمل‌های push / pull داکر استفاده کنید.
حالا که یک نسخه مخزنی از پکیج Axigen خودمان ایجاد کردیم، یک پکیج جدید از نرم‌افزار داریم که امکان نصب آن در محیط ابر وجود دارد.
بخش دوم این سری از مطالب ما هم آماده است که در آن درباره نحوه ایجاد و اجرای محیط ایمیل سرور در کوبرنتیز روی پلتفرم ابر گوگل صحبت می‌کنیم.
نکته: Axigen یک ایمیج داکر کاملاً کاربردی و آماده استفاده در داکر هاب دارد که می‌توانید از طریق این لینک به آن دسترسی پیدا کنید.
اگر قصد نصب یک ایمیل سرور Axigen کلاسترسازی شده روی پلتفرم‌های کوبرنتیز را دارید، می‌توانید از Axigen Helm ما استفاده کنید که مثل ایمیل داکر Axigen برای استفاده‌های واقعی طراحی و آماده شده است.
[1] در مقیاس‌پذیری افقی می‌توانید منابع را افزایش یا کاهش دهید.
[2] مدیران و کاربران سیستم با استفاده از ابزار RPM می‌توانند بسته‌های نرم‌افزاری را در لینوکس و یونیکس نصب و مدیریت کنند.
[3] کاربران داکر می‌توانند ایمیج‌های کانتینر را در داکر هاب ایجاد و مدیریت کنند.
[4] داکر کانتینر ایمیج (Docker Container Image) یک بسته نرم‌افزاری قابل اجرا است و کلیه مواردی که برای اجرای یک برنامه لازم است را در بر می‌گیرد.
منبع: axigen
