סדנת RHEL 8 Beta: בניית יישומי אינטרנט עובדים

RHEL 8 Beta מציע למפתחים תכונות חדשות רבות, שהרשימה שלהן עשויה לקחת דפים, עם זאת, למידה של דברים חדשים היא תמיד טובה יותר בפועל, אז להלן אנו מציעים סדנה ליצירת תשתית אפליקציה המבוססת על Red Hat Enterprise Linux 8 Beta.

בואו ניקח את Python, שפת תכנות פופולרית בקרב מפתחים, כבסיס, שילוב של Django ו-PostgreSQL, שילוב נפוץ למדי ליצירת אפליקציות, ונקבע את RHEL 8 Beta לעבוד איתם. לאחר מכן נוסיף עוד כמה מרכיבים (לא מסווגים).

סביבת הבדיקה תשתנה, כי מעניין לחקור את האפשרויות של אוטומציה, עבודה עם קונטיינרים וניסיון של סביבות עם מספר שרתים. כדי להתחיל עם פרויקט חדש, אתה יכול להתחיל ביצירת אב טיפוס קטן ופשוט ביד כדי שתוכל לראות בדיוק מה צריך לקרות ואיך הוא מקיים אינטראקציה, ולאחר מכן לעבור לאוטומציה וליצור תצורות מורכבות יותר. היום אנחנו מדברים על יצירת אב טיפוס כזה.

נתחיל בפריסת תמונת RHEL 8 Beta VM. אתה יכול להתקין מכונה וירטואלית מאפס, או להשתמש בתמונת אורח KVM הזמינה עם מנוי הביטא שלך. בעת שימוש בתמונת אורח, תצטרך להגדיר תקליטור וירטואלי שיכיל מטא נתונים ונתוני משתמש לאתחול ענן (cloud-init). אתה לא צריך לעשות שום דבר מיוחד עם מבנה הדיסק או החבילות הזמינות; כל תצורה תתאים.

בואו נסתכל מקרוב על כל התהליך.

התקנת ג'נגו

עם הגרסה החדשה ביותר של Django, תזדקק לסביבה וירטואלית (virtualenv) עם Python 3.5 ואילך. בהערות הבטא תוכלו לראות ש-Python 3.6 זמין, בואו נבדוק אם זה אכן המקרה:

[cloud-user@8beta1 ~]$ python
-bash: python: command not found
[cloud-user@8beta1 ~]$ python3
-bash: python3: command not found

Red Hat משתמש באופן פעיל ב-Python כערכת כלים מערכתית ב-RHEL, אז למה זה תוצאה?

העובדה היא שמפתחי Python רבים עדיין שוקלים את המעבר מ-Python 2 לפייתון 2, בעוד ש-Python 3 עצמו נמצא בפיתוח פעיל, ועוד ועוד גרסאות חדשות מופיעות ללא הרף. לכן, כדי לענות על הצורך בכלי מערכת יציבים תוך מתן גישה למשתמשים לגרסאות חדשות שונות של Python, מערכת Python הועברה לחבילה חדשה וסיפקה את היכולת להתקין גם Python 2.7 וגם 3.6. מידע נוסף על השינויים ומדוע בוצעו ניתן למצוא בפרסום ב הבלוג של לנגדון ווייט (לנגדון ווייט).

אז כדי להתחיל לעבוד ב-Python, אתה רק צריך להתקין שתי חבילות, עם python3-pip כלולה כתלות.

sudo yum install python36 python3-virtualenv

למה לא להשתמש בקריאות מודול ישירות כפי שלנגדון מציע ולהתקין pip3? בהתחשב באוטומציה הקרובה, ידוע ש-Ansible ידרוש התקנת pip כדי לפעול, מכיוון שמודול ה-pip אינו תומך ב-virtualenvs עם קובץ הפעלה מותאם אישית של pip.

עם מתורגמן python3 עובד לרשותכם, תוכלו להמשיך בתהליך ההתקנה של Django ולקבל מערכת עובדת יחד עם שאר הרכיבים שלנו. ישנן אפשרויות יישום רבות הזמינות באינטרנט. יש כאן גרסה אחת, אך משתמשים יכולים להשתמש בתהליכים משלהם.

נתקין את גרסאות PostgreSQL ו-Nginx הזמינות ב-RHEL 8 כברירת מחדל באמצעות Yum.

sudo yum install nginx postgresql-server

PostgreSQL ידרוש psycopg2, אבל הוא צריך להיות זמין רק בסביבת Virtualenv, אז נתקין אותו באמצעות pip3 יחד עם Django ו-Gunicorn. אבל תחילה עלינו להגדיר את virtualenv.

תמיד יש הרבה ויכוחים בנושא בחירת המקום הנכון להתקנת פרויקטי Django, אך כאשר יש ספק, אתה תמיד יכול לפנות לתקן ההיררכיה של מערכת הקבצים של לינוקס. באופן ספציפי, ה-FHS אומר ש-/srv משמש ל: "לאחסן נתונים ספציפיים למארח - נתונים שהמערכת מייצרת, כגון נתונים וסקריפטים של שרת אינטרנט, נתונים המאוחסנים בשרתי FTP ובקרה על מאגרי מערכת." גרסאות (מופיעות ב-FHS -2.3 בשנת 2004)."

זה בדיוק המקרה שלנו, אז אנחנו מכניסים את כל מה שאנחנו צריכים לתוך /srv, שהוא בבעלות משתמש האפליקציה שלנו (Cloud-User).

sudo mkdir /srv/djangoapp
sudo chown cloud-user:cloud-user /srv/djangoapp
cd /srv/djangoapp
virtualenv django
source django/bin/activate
pip3 install django gunicorn psycopg2
./django-admin startproject djangoapp /srv/djangoapp

הגדרת PostgreSQL ו-Django היא קלה: צור מסד נתונים, צור משתמש, הגדר הרשאות. דבר אחד שיש לזכור בעת התקנת PostgreSQL לראשונה הוא סקריפט postgresql-setup שמותקן עם חבילת postgresql-server. סקריפט זה עוזר לך לבצע משימות בסיסיות הקשורות לניהול אשכול מסד נתונים, כגון אתחול אשכול או תהליך השדרוג. כדי להגדיר מופע PostgreSQL חדש במערכת RHEL, עלינו להפעיל את הפקודה:

sudo /usr/bin/postgresql-setup -initdb

לאחר מכן תוכל להפעיל את PostgreSQL באמצעות systemd, ליצור מסד נתונים ולהגדיר פרויקט ב-Django. זכור להפעיל מחדש את PostgreSQL לאחר ביצוע שינויים בקובץ התצורה של אימות הלקוח (בדרך כלל pg_hba.conf) כדי להגדיר אחסון סיסמאות עבור משתמש האפליקציה. אם אתה נתקל בקשיים אחרים, הקפד לשנות את הגדרות IPv4 ו-IPv6 בקובץ pg_hba.conf.

systemctl enable -now postgresql

sudo -u postgres psql
postgres=# create database djangoapp;
postgres=# create user djangouser with password 'qwer4321';
postgres=# alter role djangouser set client_encoding to 'utf8';
postgres=# alter role djangouser set default_transaction_isolation to 'read committed';
postgres=# alter role djangouser set timezone to 'utc';
postgres=# grant all on DATABASE djangoapp to djangouser;
postgres=# q

בקובץ /var/lib/pgsql/data/pg_hba.conf:

# IPv4 local connections:
host    all        all 0.0.0.0/0                md5
# IPv6 local connections:
host    all        all ::1/128                 md5

בקובץ /srv/djangoapp/settings.py:

# Database
DATABASES = {
   'default': {
       'ENGINE': 'django.db.backends.postgresql_psycopg2',
       'NAME': '{{ db_name }}',
       'USER': '{{ db_user }}',
       'PASSWORD': '{{ db_password }}',
       'HOST': '{{ db_host }}',
   }
}

לאחר הגדרת קובץ settings.py בפרויקט והגדרת תצורת מסד הנתונים, תוכל להפעיל את שרת הפיתוח כדי לוודא שהכל עובד. לאחר הפעלת שרת הפיתוח, כדאי ליצור משתמש אדמין על מנת לבדוק את החיבור למסד הנתונים.

./manage.py runserver 0.0.0.0:8000
./manage.py createsuperuser

WSGI? וואי?

שרת הפיתוח שימושי לבדיקה, אך כדי להפעיל את היישום עליך להגדיר את השרת וה-proxy המתאימים עבור ממשק ה-Web Server Gateway (WSGI). ישנם מספר שילובים נפוצים, למשל, Apache HTTPD עם uWSGI או Nginx עם Gunicorn.

תפקידו של ממשק שער האינטרנט של שרת האינטרנט הוא להעביר בקשות משרת האינטרנט למסגרת האינטרנט של Python. WSGI הוא שריד מהעבר הנורא כשמנועי CGI היו בסביבה, וכיום WSGI הוא התקן דה פקטו, ללא קשר לשרת האינטרנט או המסגרת של Python בשימוש. אך למרות השימוש הנרחב בו, עדיין ישנם ניואנסים רבים בעבודה עם מסגרות אלו, ואפשרויות רבות. במקרה זה, ננסה ליצור אינטראקציה בין Gunicorn ל-Nginx באמצעות שקע.

מכיוון ששני הרכיבים הללו מותקנים על אותו שרת, בואו ננסה להשתמש בשקע UNIX במקום בשקע רשת. מכיוון שתקשורת מצריכה שקע בכל מקרה, בואו ננסה לעשות עוד צעד אחד ולהגדיר את הפעלת השקע עבור Gunicorn באמצעות systemd.

התהליך של יצירת שירותים מופעלים בשקע הוא די פשוט. ראשית, נוצר קובץ יחידה המכיל הנחיית ListenStream המצביעה על הנקודה בה ייווצר שקע ה-UNIX, לאחר מכן קובץ יחידה עבור השירות שבו ההנחיה Requires תצביע על קובץ יחידת השקע. לאחר מכן, בקובץ יחידת השירות, כל שנותר הוא להתקשר ל-Gunicorn מהסביבה הווירטואלית וליצור כריכת WSGI עבור שקע UNIX ואפליקציית Django.

להלן כמה דוגמאות לקבצי יחידה שתוכל להשתמש בהם כבסיס. ראשית הגדרנו את השקע.

[Unit]
Description=Gunicorn WSGI socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

עכשיו אתה צריך להגדיר את הדמון Gunicorn.

[Unit]
Description=Gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=cloud-user
Group=cloud-user
WorkingDirectory=/srv/djangoapp

ExecStart=/srv/djangoapp/django/bin/gunicorn 
         —access-logfile - 
         —workers 3 
         —bind unix:gunicorn.sock djangoapp.wsgi

[Install]
WantedBy=multi-user.target

עבור Nginx, זה עניין פשוט של יצירת קבצי תצורת proxy והגדרת ספרייה לאחסון תוכן סטטי אם אתה משתמש באחד. ב-RHEL, קובצי התצורה של Nginx נמצאים ב- /etc/nginx/conf.d. אתה יכול להעתיק את הדוגמה הבאה לקובץ /etc/nginx/conf.d/default.conf ולהפעיל את השירות. הקפד להגדיר את server_name כך שיתאים לשם המארח שלך.

server {
   listen 80;
   server_name 8beta1.example.com;

   location = /favicon.ico { access_log off; log_not_found off; }
   location /static/ {
       root /srv/djangoapp;
   }

   location / {
       proxy_set_header Host $http_host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       proxy_set_header X-Forwarded-Proto $scheme;
       proxy_pass http://unix:/run/gunicorn.sock;
   }
}

הפעל את שקע Gunicorn ואת Nginx באמצעות systemd ואתה מוכן להתחיל בבדיקה.

שגיאת שער גרוע?

אם תזין את הכתובת בדפדפן שלך, סביר להניח שתקבל שגיאת 502 Bad Gateway. זה עשוי להיגרם מהרשאות שקע UNIX שהוגדרו בצורה שגויה, או שזה עשוי לנבוע מבעיות מורכבות יותר הקשורות לבקרת גישה ב-SELinux.

ביומן השגיאות של nginx אתה יכול לראות שורה כזו:

2018/12/18 15:38:03 [crit] 12734#0: *3 connect() to unix:/run/gunicorn.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.122.1, server: 8beta1.example.com, request: "GET / HTTP/1.1", upstream: "http://unix:/run/gunicorn.sock:/", host: "8beta1.example.com"

אם נבדוק את Gunicorn ישירות, נקבל תשובה ריקה.

curl —unix-socket /run/gunicorn.sock 8beta1.example.com

בואו נבין למה זה קורה. אם תפתח את היומן, סביר להניח שתראה שהבעיה קשורה ל-SELinux. מכיוון שאנו מפעילים דמון שלא נוצרה עבורו מדיניות, הוא מסומן כ-init_t. בואו נבדוק את התיאוריה הזו בפועל.

sudo setenforce 0

כל זה עלול לגרום לביקורת ודמעות של דם, אבל זה רק ניפוי אבטיפוס. בוא ננטרל את הצ'ק רק כדי לוודא שזו הבעיה ולאחר מכן נחזיר הכל למקומו.

על ידי רענון הדף בדפדפן או הפעלה חוזרת של פקודת הסלסול שלנו, תוכל לראות את דף הבדיקה של Django.

אז, לאחר שווידאתם שהכל עובד ושאין עוד בעיות הרשאה, אנו מפעילים את SELinux שוב.

sudo setenforce 1

אין כאן דיבור על audit2allow או על יצירת מדיניות מבוססת התראות עם sepolgen, מכיוון שכרגע אין אפליקציית Django אמיתית, כך שאין מפה שלמה של מה ש-Gunicorn עשוי לרצות לגשת ולמה עליו למנוע גישה. לכן, יש צורך להשאיר את SELinux פועל כדי להגן על המערכת, ובו בזמן לאפשר לאפליקציה לפעול ולהשאיר הודעות ביומן הביקורת, כך שניתן יהיה ליצור מהן את המדיניות בפועל.

ציון תחומים מתירים

לא כולם שמעו על דומיינים מותרים ב-SELinux, אבל הם לא חדשים. רבים אפילו עבדו איתם מבלי להבין זאת. כאשר מדיניות נוצרת על סמך הודעות ביקורת, המדיניות שנוצרה מייצגת את התחום שנפתר. בואו ננסה ליצור מדיניות אישור פשוטה.

כדי ליצור דומיין מותר ספציפי עבור Gunicorn, אתה צריך סוג של מדיניות, ואתה צריך גם לסמן את הקבצים המתאימים. בנוסף, דרושים כלים להרכבת פוליסות חדשות.

sudo yum install selinux-policy-devel

מנגנון התחומים המותרים הוא כלי מצוין לזיהוי בעיות, במיוחד כשמדובר באפליקציה מותאמת אישית או יישומים הנשלחים ללא מדיניות שכבר נוצרה. במקרה זה, מדיניות הדומיין המותרת עבור Gunicorn תהיה פשוטה ככל האפשר - הכרזה על סוג ראשי (gunicorn_t), הכרזה על סוג שבו נשתמש כדי לסמן מספר קובצי הפעלה (gunicorn_exec_t), ולאחר מכן הגדר מעבר למערכת לסימון נכון ריצה תהליכים. השורה האחרונה מגדירה את המדיניות כמופעלת כברירת מחדל בזמן טעינתה.

gunicorn.te:

policy_module(gunicorn, 1.0)

type gunicorn_t;
type gunicorn_exec_t;
init_daemon_domain(gunicorn_t, gunicorn_exec_t)
permissive gunicorn_t;

אתה יכול להרכיב קובץ מדיניות זה ולהוסיף אותו למערכת שלך.

make -f /usr/share/selinux/devel/Makefile
sudo semodule -i gunicorn.pp

sudo semanage permissive -a gunicorn_t
sudo semodule -l | grep permissive

בואו נבדוק אם SELinux חוסם משהו אחר מלבד מה שהדמון הלא ידוע שלנו ניגש אליו.

sudo ausearch -m AVC

type=AVC msg=audit(1545315977.237:1273): avc:  denied { write } for pid=19400 comm="nginx" name="gunicorn.sock" dev="tmpfs" ino=52977 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_run_t:s0 tclass=sock_file permissive=0

SELinux מונעת מ-Nginx לכתוב נתונים לשקע UNIX המשמש את Gunicorn. בדרך כלל, במקרים כאלה, המדיניות מתחילה להשתנות, אבל יש אתגרים אחרים לפנינו. אתה יכול גם לשנות את הגדרות הדומיין מתחום הגבלה לתחום הרשאה. כעת נעביר את httpd_t לתחום ההרשאות. זה ייתן ל-Nginx את הגישה הדרושה ונוכל להמשיך בעבודת ניפוי באגים נוספת.

sudo semanage permissive -a httpd_t

אז ברגע שהצלחת לשמור על SELinux מוגן (ממש לא כדאי לך להשאיר פרויקט SELinux במצב מוגבל) ודומייני ההרשאה נטענים, אתה צריך להבין מה בדיוק צריך להיות מסומן כ-gunicorn_exec_t כדי שהכל יעבוד כמו שצריך שוב. בואו ננסה לבקר באתר כדי לראות הודעות חדשות על הגבלות גישה.

sudo ausearch -m AVC -c gunicorn

אתה תראה הרבה הודעות המכילות 'comm="gunicorn"' שעושות דברים שונים בקבצים ב-/srv/djangoapp, אז ברור שזו אחת הפקודות ששווה לסמן.

אבל בנוסף, מופיעה הודעה כזו:

type=AVC msg=audit(1545320700.070:1542): avc:  denied { execute } for pid=20704 comm="(gunicorn)" name="python3.6" dev="vda3" ino=8515706 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file permissive=0

אם תסתכל על הסטטוס של שירות הגוניקורן או תפעיל את הפקודה ps, לא תראה תהליכים פועלים. נראה ש-gunicorn מנסה לגשת למתורגמן Python בסביבת הווירטואלי שלנו, אולי כדי להריץ סקריפטים של עובדים. אז עכשיו בואו נסמן את שני קבצי ההפעלה הללו ונבדוק אם נוכל לפתוח את דף הבדיקה שלנו ב-Django.

chcon -t gunicorn_exec_t /srv/djangoapp/django/bin/gunicorn /srv/djangoapp/django/bin/python3.6

יהיה צורך להפעיל מחדש את שירות הגוניקורן לפני שניתן יהיה לבחור בתג החדש. אתה יכול להפעיל אותו מחדש מיד או להפסיק את השירות ולתת לשקע להפעיל אותו כאשר אתה פותח את האתר בדפדפן. ודא שתהליכים קיבלו את התוויות הנכונות באמצעות ps.

ps -efZ | grep gunicorn

אל תשכח ליצור מדיניות SELinux רגילה מאוחר יותר!

אם תסתכל עכשיו על הודעות AVC, ההודעה האחרונה מכילה permissive=1 לכל מה שקשור לאפליקציה, ומתיר=0 עבור שאר המערכת. אם אתה מבין איזה סוג של גישה צריך יישום אמיתי, אתה יכול למצוא במהירות את הדרך הטובה ביותר לפתור בעיות כאלה. אבל עד אז, עדיף לשמור על אבטחת המערכת ולקבל ביקורת ברורה ושמישה של פרויקט Django.

sudo ausearch -m AVC

קרה!

פרויקט Django עובד הופיע עם חזית המבוססת על Nginx ו-Gunicorn WSGI. הגדרנו את Python 3 ו- PostgreSQL 10 ממאגרי RHEL 8 Beta. כעת אתה יכול להתקדם וליצור (או פשוט לפרוס) יישומי Django או לחקור כלים זמינים אחרים ב-RHEL 8 Beta כדי להפוך את תהליך התצורה לאוטומטי, לשפר את הביצועים, או אפילו למכל את התצורה הזו.

מקור: www.habr.com