גישה למכונה של Looker (Google Cloud core) באמצעות גישה לשירותים פרטיים

בדף הזה מוסבר איך להגדיר דומיין בהתאמה אישית וגישה למופע של Looker (Google Cloud core) שעומד בשני הקריטריונים הבאים:

כדי לגשת לסוג כזה של מופע:

  1. הגדרת הדומיין המותאם אישית.
  2. יצירת מכונות וירטואליות ואזור פרטי.
  3. מגדירים את שרתי ה-proxy ההפוך.
  4. יצירה והגדרה של מאזן העומסים.
  5. יצירת כללים לחומת האש.
  6. מעדכנים את רשומת ה-A ב-DNS.
  7. עדכון פרטי הכניסה של OAuth.

הגדרת דומיין מותאם אישית

אחרי שיוצרים את המכונה של Looker (Google Cloud core), אפשר להגדיר דומיין בהתאמה אישית.

לפני שמתחילים

לפני שמתאימים אישית את הדומיין של מופע Looker (Google Cloud core), צריך לזהות איפה מאוחסנות רשומות ה-DNS של הדומיין כדי שתוכלו לעדכן אותן.

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות ליצירת דומיין בהתאמה אישית למופע של Looker (Google Cloud core), צריך לבקש מהאדמין להקצות לכם את תפקיד ה-IAM‏ Looker Admin (roles/looker.admin) בפרויקט שבו נמצא המופע. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

יצירת דומיין מותאם אישית

כדי להתאים אישית את הדומיין של מופע Looker (Google Cloud core) במסוף Google Cloud :

  1. בדף Instances (מכונות), לוחצים על השם של המכונה שרוצים להגדיר לה דומיין מותאם אישית.
  2. לוחצים על הכרטיסייה דומיין מותאם אישית.

  3. לוחצים על הוספת דומיין מותאם אישית.

    תיפתח החלונית הוספת דומיין מותאם אישית חדש.

  4. מזינים את שם המארח של דומיין האינטרנט שרוצים להשתמש בו, באורך של עד 64 תווים, תוך שימוש רק באותיות, במספרים ובמקפים – לדוגמה: looker.examplepetstore.com.

  5. לוחצים על הלחצן המשך.

  6. הקטע עדכון רשומות ה-DNS ייפתח. כתובת ה-IP הציבורית של התנועה הנכנסת מופיעה בשדה Data.

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

העדכון של הדומיין המותאם אישית נמשך 10 עד 15 דקות.

אחרי שמגדירים את הדומיין המותאם אישית, הוא מוצג בעמודה Domain בכרטיסייה CUSTOM DOMAIN בדף פרטי המופע של Looker (Google Cloud core) ב Google Cloud מסוף.

אחרי שיוצרים דומיין מותאם אישית, אפשר לראות מידע עליו או למחוק אותו.

גישה לדומיין המותאם אישית

כשמקור התנועה למכונת Looker (ליבת Google Cloud) עם חיבורים פרטיים (PSA) הוא מאזור אחר מהמכונה, אפשר להשתמש בשרת פרוקסי הפוך אחד או יותר עם כתובת IP פרטית ובמאזן עומסים כדי לספק גישה מאובטחת למכונה.

לפני שמתחילים

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

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

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

סקירה כללית על רשתות

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

רשת Google Cloud שבה מוצגת גישה מאובטחת למופע Looker (ליבת Google Cloud) באמצעות Cloud Router, מאזן עומסים פנימי וגישה לשירותים פרטיים.

יצירת מכונות וירטואליות, אזור פרטי ורשומת A

מבצעים את השלבים בקטעים הבאים.

יצירת מכונות וירטואליות

יוצרים שתי מכונות וירטואליות עם כתובות IP פרטיות בלבד ומערכת הפעלה RHEL. המכונות הווירטואליות ישמשו כשרתי proxy. הם צריכים להיות באותו אזור כמו מופע Looker (Google Cloud core), אבל באזורים שונים זה מזה.

יצירת אזור פרטי

יוצרים תחום פרטי ב-Cloud DNS שגלוי ל-VPC שבו נמצא מופע Looker (Google Cloud core). האזור הפרטי של Cloud DNS ישמש את ה-VPC ואת המארחים המקומיים לפתרון DNS כדי להגיע לממשק המשתמש של Looker (ליבת Google Cloud). שם האזור צריך להיות זהה לדומיין המותאם אישית.

  gcloud dns managed-zones create NAME \
  --description=DESCRIPTION \
  --dns-name=DNS_SUFFIX \
  --networks=VPC_NETWORK_LIST \
  --labels=LABELS \
  --visibility=private

מחליפים את מה שכתוב בשדות הבאים:

  • ‫NAME: שם לאזור.
  • ‫DESCRIPTION: תיאור של האזור.

  • ‫DNS_SUFFIX: סיומת ה-DNS של האזור, למשל examplepetstore.com.

  • ‫VPC_NETWORK_LIST: רשימה מופרדת בפסיקים של רשתות VPC שמורשות לשלוח שאילתות לאזור. חשוב לכלול את ה-VPC שמכיל את המכונה של Looker (ליבת Google Cloud).

  • ‫LABELS: רשימה אופציונלית של זוגות של מפתח וערך שמופרדים בפסיקים, כמו dept=marketing או project=project1. מידע נוסף זמין במסמכי התיעוד בנושא SDK.

אחרי שמגדירים את האזור, אם עוברים לאזור בדף Cloud DNS zones במסוף Google Cloud , אפשר לראות שהוא פרטי, שהוא נקרא על שם הדומיין המותאם אישית ושיש לו קבוצות רשומות לדומיין המותאם אישית.

הוספה של רשומת A ב-Cloud DNS

כדי להוסיף את רשומת ה-A של Cloud DNS:

  1. מכיוון שתשתמשו במאזן עומסים, רשומת ה-A באזור הפרטי של Cloud DNS תמופה לכתובת ה-IP של מאזן העומסים.

    כתובת ה-IP של הכניסה מסומנת בכרטיסייה Details (פרטים) בדף Instances (מופעים).

  2. מוסיפים רשומת DNS מסוג A לדומיין המותאם אישית באזור הפרטי, שכוללת את כתובת ה-IP של הכניסה למופע Looker (Google Cloud core). רשומת ה-A משתמשת בשם הדומיין שמוגדר במלואו (FQDN), כמו שם הדומיין המותאם אישית שהגדרתם ל-Looker (Google Cloud core).

    אחרי ההגדרה, כשמציגים את הפרטים של האזור הפרטי בדף Cloud DNS zones ב- Google Cloud console, אמורה להופיע רשומת ה-A של הדומיין המותאם אישית.

    אחרי שרשומות ה-DNS של הדומיין יעודכנו והדומיין יאומת במסוף Google Cloud, הסטטוס של הדומיין המותאם אישית שממופה למופע יעודכן. במקרים של מכונות שמשתמשות רק ברשת פרטית, יכול להיות שהסטטוס יישאר לא מאומת כי Google לא יכולה לאמת רשומות DNS פרטיות או להגיע לכתובות IP פנימיות של המכונה. גם אם הסטטוס הוא לא מאומת, עדיין אפשר להשתמש בדומיין המותאם אישית.

הגדרת שרתי ה-proxy ההפוך

אפשר להשתמש בכל שרת אינטרנט שאפשר להגדיר כשרת proxy הפוך. כדי לראות דוגמאות להגדרת שרתי proxy הפוך באמצעות NGINX או Apache, בוחרים באחת מהאפשרויות הבאות:

NGINX

בדוגמה הבאה נעשה שימוש בגרסה 1.22.1 של NGINX ובגרסה 8.9 של Red Hat Enterprise Linux‏ (Ootpa). כדי לבדוק באילו גרסאות של NGNIX ו-Red Hat נעשה שימוש במכונות הווירטואליות, מריצים את הפקודות הבאות לכל מכונה וירטואלית.

  1. קודם כל, מתחברים ל-VM.

  2. מתקינים את NGINX באמצעות הפקודה הבאה:

    sudo yum install nginx -y

  3. כדי למצוא את גרסת NGINX שפועלת במכונת ה-VM, מריצים את הפקודה הבאה: 

    sudo nginx -v

    אמורה להתקבל תגובה שדומה לזו:

    nginx version: nginx/1.22.1

  4. כדי לבדוק איזו גרסת NGINX מופעלת במכונה הווירטואלית, מריצים את הפקודה הבאה: 

    sudo rpm -qi nginx | grep Release

    אמורה להתקבל תגובה שדומה לזו:

    Release : 1.module+el8.8.0+20355+6d9c8a63.1

  5. כדי לבדוק באיזו גרסה של Red Hat נעשה שימוש במכונות הווירטואליות, מריצים את הפקודה הבאה:

    sudo cat /etc/redhat-release

כדי להגדיר כל שרת proxy, פועלים לפי ההוראות הבאות לכל אחת משתי המכונות הווירטואליות שיצרתם.

  1. מתחברים ל-VM.

  2. עורכים את קובץ /etc/nginx/nginx.conf כך שיכיל את ההגדרות הבאות:

    events {
  worker_connections 1024;
}

http {
  log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

  log_format debug  '$http_x_forwarded_for - $remote_user [$time_local] '
                    '"$request_method $scheme://$host$request_uri $server_protocol" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" $request_time';

  access_log  /var/log/nginx/access.log  debug;

  sendfile            on;
  tcp_nopush          on;
  keepalive_timeout   65;
    types_hash_max_size 4096;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

server {
  listen 443 ssl;
  # listen [::]:443 ssl;
  include snippets/self-signed.conf;
  # include snippets/ssl-params.conf;
  server_name CUSTOM_DOMAIN;
  location / {
    proxy_pass https://INGRESS_PRIVATE_IP/$request_uri;
    proxy_set_header Host $server_name;
    proxy_http_version 1.1;
  }
}
server {
  listen 80;
  # listen [::]:80;
  server_name CUSTOM_DOMAIN;
  return 302 https://$server_name$request_uri;
  }
}

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫CUSTOM_DOMAIN: הדומיין המותאם אישית של מופע Looker (Google Cloud Core)‎
    • ‫INGRESS_PRIVATE_IP: כתובת ה-IP של הכניסה למופע של Looker (Google Cloud core)

    בנוסף, כדאי לשים לב לנקודות הבאות:

    • זוהי הגדרה של IPv4 בלבד. אם אתם רוצים שהפרוקסי יאזין גם לכתובת ה-IPv6 שלו, צריך לבטל את ההערה בשורה listen [::]:443 ssl בקובץ.
    • רמת הגישה ליומן מוגדרת ל-debug. חשוב לשנות אותה לרמה שמשמשת בסביבה הספציפית שלכם.
    • אם מטמיעים את הקובץ ssl-params.conf, שמוזכר בהמשך השלבים האלה, מבטלים את ההערה include snippets/ssl-params.conf.

  3. יוצרים אישור TLS תקין שמפנה לכתובת ה-URL של הדומיין המותאם אישית של Looker (Google Cloud core). האישור הזה הוא האישור ששרת ה-proxy מציג ללקוחות שמנסים לגשת ל-Looker (Google Cloud core). רשות האישורים (CA) שמשמשת לחתימה על האישור צריכה להיות מהימנה על ידי הלקוחות שלכם. אפשר גם להשתמש ברשות אישורים פרטית פנימית כדי לחתום על אישור ה-TLS הזה. (אפשר גם להשתמש באישור SSL בניהול עצמי).

    בדוגמה הזו, נניח שהאישור כבר נוצר באמצעות השירות החינמי Let's Encrypt, בלי להגדיר חידוש אוטומטי דרך Certbot. אחרי שיוצרים את האישור, שומרים את הקבצים הרלוונטיים בספריות certs ו-private בכל מכונת VM של שרת proxy:

    /etc/pki/tls/certs/custom-domain.custom-domain.com.fullchain.pem;
/etc/pki/tls/private/custom-domain.custom-domain.com.key.pem;

    מחליפים את custom-domain.custom-domain.com בדומיין המותאם אישית.

    אם הספריות certs ו-private לא קיימות בהתקנה, אפשר ליצור אותן או להשתמש בתיקיות אחרות.

  4. כדי לוודא ש-NGINX יזהה את קובצי האישורים, יוצרים את הספרייה /etc/nginx/snippets:

    sudo mkdir /etc/nginx/snippets

  5. יוצרים את קובץ התצורה, /etc/nginx/snippets/self-signed.conf:

    sudo touch /etc/nginx/snippets/self-signed.conf

    עורכים את קובץ התצורה כדי להוסיף את הנתיבים לקבצי האישורים ששמרתם:

    ssl_certificate /etc/pki/tls/certs/custom-domain.custom-domain.com.fullchain.pem;
ssl_certificate_key /etc/pki/tls/private/custom-domain.custom-domain.com.key.pem;

    מחליפים את custom-domain.custom-domain.com בדומיין המותאם אישית.

  6. כדי לוודא שקובץ התצורה מכיל את ההפניה לקבצים שצוינו בשלב הקודם, מריצים את הפקודה הבאה: 

    sudo more /etc/nginx/snippets/self-signed.conf

    הפלט צריך לכלול את נתיבי הקבצים שהוספתם.

  7. אפשר גם ליצור את קובץ NGINX‏ ssl-params.conf, שבו אפשר לאחסן פרמטרים שאפשר להשתמש בהם שוב בהגדרות עתידיות של NGINX.

    לדוגמה, התוכן של הקובץ צריך להיראות בערך כך:

    ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/dhparam.pem;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
ssl_ecdh_curve secp384r1;
ssl_session_timeout  10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 127.0.0.53 valid=300s;
resolver_timeout 5s;
# Disable strict transport security for now. You can uncomment the following
# line if you understand the implications.
#add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";

  8. כדי להגדיר את SELinux כך שיאפשר ל-NGINX להעביר תנועה לכתובת ה-IP של כניסת הנתונים (ingress) של Looker (Google Cloud core), צריך להגדיר את הפרמטר הבוליאני של SELinux‏ httpd_can_network_connect ל-1:

    sudo setsebool -P httpd_can_network_connect 1

  9. עכשיו אפשר להפעיל מחדש את תהליך NGINX באמצעות הפקודה הבאה:

    sudo systemctl restart nginx

  10. כדי לוודא ש-NGINX הופעל מחדש בצורה תקינה, מריצים את הפקודה הבאה:

    sudo systemctl status nginx

    הפלט שמתקבל אמור להיות דומה לזה:

    nginx.service - The nginx HTTP and reverse proxy server
  Loaded: loaded (/usr/lib/systemd/system/nginx.service; disabled; vendor preset: disabled)
  Active: active (running) since Tue 2024-05-14 11:58:00 UTC; 9min ago
  Process: 144044 ExecStart=/usr/sbin/nginx (code=exited, status=0/SUCCESS)
  Process: 144042 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=0/SUCCESS)
  Process: 144039 ExecStartPre=/usr/bin/rm -f /run/nginx.pid (code=exited, status=0/SUCCESS)
Main PID: 144045 (nginx)
    Tasks: 2 (limit: 11040)
  Memory: 2.6M
  CGroup: /system.slice/nginx.service
          ├─144045 nginx: master process /usr/sbin/nginx
          └─144046 nginx: worker process
May 14 11:58:00 proxy-three-eu-w4 systemd[1]: nginx.service: Succeeded.
May 14 11:58:00 proxy-three-eu-w4 systemd[1]: Stopped The nginx HTTP and reverse proxy server.
May 14 11:58:00 proxy-three-eu-w4 systemd[1]: Starting The nginx HTTP and reverse proxy server...
May 14 11:58:00 proxy-three-eu-w4 nginx[144042]: nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
May 14 11:58:00 proxy-three-eu-w4 nginx[144042]: nginx: configuration file /etc/nginx/nginx.conf test is successful
May 14 11:58:00 proxy-three-eu-w4 systemd[1]: Started The nginx HTTP and reverse proxy server.

Apache

מבצעים את השלבים האלה לכל מכונה וירטואלית.

  1. קודם כל, מתחברים ל-VM.

  2. מתקינים את Apache:

    sudo yum install httpd -y

  3. בדוגמה הבאה נעשה שימוש ב-Red Hat Enterprise Linux בגרסה 7.9. כדי לבדוק באיזו גרסה של Red Hat נעשה שימוש במכונות הווירטואליות, מריצים את הפקודה הבאה:

    cat /etc/redhat-release

    הפלט הבא אמור להתקבל:

    Red Hat Enterprise Linux Server release 7.9 (Maipo)

  4. בדוגמה הבאה נעשה שימוש בגרסה 2.4.6 של Apache. כדי לבדוק באילו גרסאות של Apache נעשה שימוש במכונות הווירטואליות, מריצים את הפקודות הבאות לכל מכונה וירטואלית:

    sudo httpd -version

    הפלט הבא אמור להתקבל:

    Server version: Apache/2.4.6 (Red Hat Enterprise Linux)
Server built:   date

  5. כדי לקבל מידע נוסף על שרת Apache, מריצים את הפקודה הבאה:

    sudo rpm -qi httpd

    הפלט שמתקבל אמור להיות דומה לזה:

    Name        : httpd
Version     : 2.4.6
Release     : 99.el7_9.1
Architecture: x86_64
Install Date: Tue May  7 15:48:59 2024
Group       : System Environment/Daemons
Size        : 3899819
License     : ASL 2.0
Signature   : RSA/SHA256, Fri Apr 28 17:09:45 2023, Key ID 199e2f91fd431d51
Source RPM  : httpd-2.4.6-99.el7_9.1.src.rpm
Build Date  : Fri Apr 28 16:56:11 2023
Build Host  : x86-vm-40.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. 
Vendor      : Red Hat, Inc.
URL         : http://httpd.apache.org/
Summary     : Apache HTTP Server
Description :
The Apache HTTP Server is a powerful, efficient, and extensible
web server.

  6. יוצרים את קובץ ההגדרות /etc/httpd/conf.d/ssl.conf במכונת ה-VM של ה-proxy ומוסיפים לקובץ את ההגדרות הבאות:

    ServerName custom domain of Looker (Google Cloud core)
#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on
#   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
SSLProtocol all -SSLv2 -SSLv3
#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
SSLCipherSuite HIGH:3DES:!aNULL:!MD5:!SEED:!IDEA
#   Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.  If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.  Note that a kill -HUP will prompt again.  A new
# certificate can be generated using the genkey(1) command.
# SSLCertificateFile /etc/pki/tls/certs/localhost.crt
SSLCertificateFile "/etc/pki/tls/certs/custom domain of Looker (Google Cloud core).crt"
#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
# SSLCertificateKeyFile /etc/pki/tls/private/localhost.key
SSLCertificateKeyFile "/etc/pki/tls/private/custom domain of Looker (Google Cloud core).key"
SSLProxyEngine On
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
ProxyPreserveHost On
RewriteEngine On
AllowEncodedSlashes NoDecode
ProxyPass / https://private IP of Looker (Google Cloud core)>:443/
RewriteCond %{REQUEST_URI} ^/render/
RewriteRule ^(.*)$ https://private IP of Looker (Google Cloud core)>:443/$1 [P]
RewriteRule ^(.*)$ https://private IP of Looker (Google Cloud core)>:443/$1 [P,NE]
ProxyPassReverse / https://private IP of Looker (Google Cloud core):443/

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫custom domain of Looker (Google Cloud core): הדומיין המותאם אישית של מופע Looker (Google Cloud Core).
    • ‫private IP of Looker (Google Cloud core): כתובת ה-IP הפרטית של מכונת Looker (Google Cloud core).

  7. מוודאים שקובצי אישור ה-TLS זמינים בספריות שמצוינות בקובץ /etc/httpd/conf.d/ssl.conf:

    SSLCertificateFile "/etc/pki/tls/certs/custom domain of Looker (Google Cloud core).crt"
SSLCertificateKeyFile "/etc/pki/tls/private/custom domain of Looker (Google Cloud core).key"

  8. בודקים אם mod_ssl מותקן:

    sudo yum list installed | grep mod_ssl

    אם mod_ssl לא מותקן, מתקינים אותו באמצעות הפקודה הבאה:

    sudo yum install mod_ssl

    אחרי שמתקינים את mod_ssl, צריך להפעיל אותו על ידי הוספת השורה הבאה לקובץ התצורה של Apache‏, /etc/httpd/conf/httpd.conf:

    LoadModule ssl_module modules/mod_ssl.so

  9. בקובץ התצורה של Apache‏, /etc/httpd/conf/httpd.conf, מחליפים את Listen 80 ב-Listen 443.

  10. מריצים את הפקודה הבאה כדי לאפשר למכונת ה-VM של Apache proxy להעביר תנועה ל-Looker (Google Cloud core):

    /usr/sbin/setsebool -P httpd_can_network_connect 1

  11. לבסוף, מפעילים מחדש את Apache כדי להחיל את השינויים:

    sudo systemctl restart httpd

  12. כדי לוודא שמודול הכתיבה מחדש נטען ומוכן ב-Apache, משתמשים בפקודה הבאה:

    sudo httpd -M | grep rewrite

    הפלט שמתקבל אמור להיות דומה לזה:

    rewrite_module (shared)

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

    sudo systemctl restart httpd

  14. כדי לוודא שתהליך Apache הופעל מחדש בצורה תקינה, משתמשים בפקודה הבאה: 

    sudo systemctl status httpd

    הפלט שמתקבל אמור להיות דומה לזה:

    httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
Active: active (running) since Tue 2024-05-14 15:41:57 UTC; 1s ago
  Docs: man:httpd(8)
        man:apachectl(8)
Main PID: 1400 (httpd)
Status: "Processing requests..."
CGroup: /system.slice/httpd.service
        ├─1400 /usr/sbin/httpd -DFOREGROUND
        ├─1401 /usr/sbin/httpd -DFOREGROUND
        ├─1402 /usr/sbin/httpd -DFOREGROUND
        ├─1403 /usr/sbin/httpd -DFOREGROUND
        ├─1404 /usr/sbin/httpd -DFOREGROUND
        └─1405 /usr/sbin/httpd -DFOREGROUND
May 14 15:41:57 proxy-ingress-apache systemd[1]: Starting The Apache HTTP Server...
May 14 15:41:57 proxy-ingress-apache systemd[1]: Started The Apache HTTP Server.

יצירה והגדרה של מאזן העומסים

בדוגמה הזו נעשה שימוש בקבוצות של נקודות קצה (endpoint) ברשת (NEGs) באזור עם GCE_VM_IP נקודות קצה כקצה עורפי של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי. אם אתם מעדיפים להשתמש בקצוות עורפיים שמבוססים על קבוצת מכונות, אתם יכולים לעיין בתיעוד שזמין בדף הגדרה של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי עם קצוות עורפיים של קבוצת מכונות VM.

  1. יוצרים קבוצת NEG אזורית נפרדת לכל אזור מחשוב שבו מתכננים לפרוס שרתי proxy. לדוגמה, אם רוצים לפרוס שרתי proxy בכל אחד משלושת אזורי החישוב באזור שבו נפרס Looker (Google Cloud core), צריך ליצור שלוש קבוצות אזוריות של נקודות קצה ברשת. כדי לבדוק כמה נקודות קצה נתמכות לכל קבוצת נקודות קצה אזורית, אפשר לעיין בדף התיעוד בנושא מכסות ומגבלות.

    כדי ליצור NEG אזורי, משתמשים בפקודה gcloud הבאה:

    gcloud compute network-endpoint-groups create NEG_NAME --network-endpoint-type=gce-vm-ip \
--zone=PROXY_INSTANCE_ZONE --network=PROXY_INSTANCE_VPC \
--subnet=PROXY_INSTANCE_SUBNET

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫NEG_NAME: השם של ה-NEG שאתם יוצרים.
    • ‫PROXY_INSTANCE_ZONE: האזור שבו נמצא שרת ה-proxy.
    • ‫PROXY_INSTANCE_VPC: ה-VPC שמכיל את שרת ה-Proxy.
    • ‫PROXY_INSTANCE_SUBNET: רשת המשנה שבה נמצא שרת ה-proxy.

    חוזרים על השלב הזה לכל אזור נוסף שבו תפרסו מכונה וירטואלית של שרת proxy.

  2. מוסיפים כל שרת proxy ל-NEG באותו אזור:

    gcloud compute network-endpoint-groups update NEG_NAME --zone=PROXY_INSTANCE_ZONE \
--add-endpoint='instance=PROXY_INSTANCE_NAME'

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROXY_INSTANCE_ZONE: האזור שבו נמצא שרת ה-proxy.
    • ‫NEG_NAME: השם של ה-NEG באותו אזור כמו שרת ה-proxy.
    • ‫PROXY_INSTANCE_NAME: השם של שרת ה-proxy.

    חוזרים על השלב הזה עד שכל מכונת ה-VM של שרת ה-proxy מתווספת ל-NEG כנקודת קצה.

  3. יוצרים בדיקת תקינות אזורית שתשמש את מאזן העומסים הפנימי. משתמשים בפקודה compute health-checks create:

    gcloud compute health-checks create PROTOCOL NAME \
    --region=REGION \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    PORT_SPECIFICATION \
    ADDITIONAL_FLAGS

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROTOCOL: הפרוטוקול שמשמש לבדיקת תקינות. האפשרויות התקינות הן grpc,‏ http,‏ https,‏ http2,‏ ssl ו-tcp.
    • ‫NAME: השם של בדיקת תקינות. בפרויקט נתון, לכל בדיקת תקינות גלובלית צריך להיות שם ייחודי, ולבדיקות תקינות אזוריות צריך להיות שם ייחודי באזור נתון.
    • ‫REGION: כל מאזני העומסים, למעט מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB) ומאזני עומסים פנימיים אזוריים של אפליקציות (ALB), משתמשים בבדיקות תקינות גלובליות (--global). מאזני עומסים פנימיים אזוריים של אפליקציות (ALB) משתמשים בבדיקות תקינות אזוריות, והאזור שלהן צריך להיות זהה לאזור של שירות הקצה העורפי.
    • ‫DESCRIPTION: תיאור אופציונלי.
    • ‫CHECK_INTERVAL: משך הזמן שחלף מתחילת החיבור של בקשה לבדיקת תקינות אחת ועד לתחילת החיבור של הבקשה הבאה. היחידות הן שניות. אם לא מציינים ערך,המערכת משתמשת בערך 5s (5 שניות). Google Cloud
    • ‫TIMEOUT: משך הזמן שבו Google Cloud ממתין לתגובה לבקשה לבדיקת תקינות (probe). הערך של TIMEOUT חייב להיות קטן מהערך של CHECK_INTERVAL או שווה לו. היחידות הן שניות. אם לא מציינים ערך, מערכתGoogle Cloud משתמשת בערך 5s (5 שניות).
    • ‫HEALTHY_THRESHOLD ו-UNHEALTHY_THRESHOLD: מציינים את מספר הבדיקות הרצופות שצריכות להצליח או להיכשל כדי שמכונת ה-VM תיחשב תקינה או לא תקינה. אם אחד מהם לא מצוין, Google Cloud משתמש בסף ברירת מחדל של 2.
    • ‫PORT_SPECIFICATION: הגדרת מפרט היציאה באמצעות אחד מדגלי מפרט היציאה.
    • ‫ADDITIONAL_FLAGS: דגלים אחרים לציון יציאות ואפשרויות ספציפיות ל-PROTOCOL. אפשר לעיין בדגלים נוספים לבדיקות תקינות של HTTP,‏ HTTPS ו-HTTP/2, בדגלים נוספים לבדיקות תקינות של SSL ו-TCP או בדגל נוסף לבדיקות תקינות של gRPC.

  4. יוצרים את שירות ה-Backend:

    gcloud compute backend-services create BS_NAME --load-balancing-scheme=INTERNAL \
--protocol=tcp --region=PROXY_INSTANCES_REGION --health-checks=HC_NAME \
--health-checks-region=HC_REGION --session-affinity=CLIENT_IP \
--connection-persistence-on-unhealthy-backends=NEVER_PERSIST

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫BS_NAME: השם של מאזן העומסים שאתם יוצרים.
    • ‫PROXY_INSTANCES_REGION: האזור שבו נמצאים שרתי ה-proxy.
    • ‫HC_NAME: השם של בדיקת תקינות אזורית שיצרתם.
    • ‫HC_REGION: האזור שבו נמצאת בדיקת התקינות.

    בנוסף:

    • הדגל --session-affinity=CLIENT_IP מפנה בקשה של לקוח מסוים לאותו מכונה וירטואלית של שרת proxy בעורף, על סמך hash שנוצר גם בכתובת ה-IP של הלקוח וגם בכתובת היעד.
    • הדגל --connection-persistence-on-unhealthy-backends=NEVER_PERSIST מציין שהחיבורים לא יישמרו במכונות וירטואליות של מופעי proxy לא תקינים.

  5. מוסיפים כל אחת מקבוצות ה-NEG לשירות לקצה העורפי:

    gcloud compute backend-services add-backend BS_NAME --region=BS_REGION \
--network-endpoint-group=NEG_NAME --network-endpoint-group-zone=NEG_ZONE

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫BS_NAME: השם של שירות הקצה העורפי שיצרתם.
    • ‫BS_REGION: האזור שבו נמצא שירות לקצה העורפי. האזור הזה צריך להיות זהה לאזור שבו נמצאים שרתי ה-Proxy.
    • ‫NEG_NAME: השם של קבוצת ה-NEG שמוסיפים.
    • ‫NEG_ZONE: האזור שבו נמצא ה-NEG.

    חוזרים על השלב הזה עבור ה-NEG הנוסף שיצרתם.

  6. שמירת כתובת IP פנימית ב-VPC בטווח כתובות ה-IP של תת-הרשת שאליה מחוברים מופעי ה-Proxy. זו תהיה כתובת ה-IP הווירטואלית (VIP) של מאזן העומסים הפנימי. הזמנת הכתובת תבטיח שאף אובייקט אחר לא ישתמש בכתובת ה-IP. כדי לשמור את כתובת ה-IP הפנימית, משתמשים בפקודה compute addresses create:

    gcloud compute addresses create ADDRESS_NAMES \
    --region REGION --subnet SUBNETWORK \
    --addresses IP_ADDRESS

    מחליפים את מה שכתוב בשדות הבאים:

    • ADDRESS_NAMES: השמות של כתובת אחת או יותר של [--purpose=SHARED_LOADBALANCER_VIP] שרוצים ליצור. אם יש כמה כתובות, צריך לציין את כולן כרשימה, ולהפריד ביניהן באמצעות רווחים – לדוגמה, example-address-1 example-address-2 example-address-3
    • ‫REGION: האזור של הבקשה.
    • ‫SUBNETWORK: רשת המשנה של כתובת ה-IP הפנימית הזו.
    • ‫IP_ADDRESS: כתובת ה-IP שרוצים לשמור, שחייבת להיות בטווח כתובות ה-IP הראשי של רשת המשנה. אם לא מציינים כתובת IP, המערכת מקצה כתובת IP באופן אוטומטי מרשת המשנה.

  7. יוצרים את כלל ההעברה ומשייכים אותו לשירות לקצה העורפי ולכתובת ה-VIP:

    gcloud compute forwarding-rules create FW_RULE_NAME --region=BS_REGION \
--load-balancing-scheme=internal --network=PROXY_INSTANCES_VPC_NAME --subnet=RESERVED_IP_ADDRESS_SUBNET \
--address=RESERVED_IP_ADDRESS --ip-protocol=tcp --ports=ALL --backend-service=BS_NAME \
--backend-service-region=BS_REGION --allow-global-access

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫FW_RULE_NAME: השם של כלל ההעברה שיוצרים.
    • ‫BS_REGION: האזור שבו נמצא שירות הקצה העורפי
    • ‫PROXY_INSTANCES_VPC_NAME: השם של ה-VPC שבו נוצרו מכונות וירטואליות של שרת proxy
    • ‫RESERVED_IP_ADDRESS_SUBNET: רשת המשנה שבה נמצאת כתובת ה-VIP
    • ‫RESERVED_IP_ADDRESS: כתובת ה-VIP של מאזן העומסים
    • ‫BS_NAME: השם של שירות הקצה העורפי

    בנוסף:

    • הדגל --allow-global-access מציין שאפשר להגיע ל-VIP של מאזן העומסים מכל אזור (לא רק מ-BS_REGION). כך לקוחות בכל אזור יכולים להגיע למופע Looker (Google Cloud core).

יצירת כללים לחומת האש

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

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

עדכון רשומת ה-A ב-DNS

משנים את רשומת ה-A של הדומיין המותאם אישית של Looker (Google Cloud core) כך שתצביע על כתובת ה-VIP של מאזן העומסים. האזור הפרטי ב-Cloud DNS שיצרתם מנהל את הדומיין המותאם אישית ומשמש את ה-VPC שבו נמצאים מופעי ה-proxy.

עדכון פרטי הכניסה של OAuth

  1. כדי לגשת ללקוח OAuth, עוברים במסוף Google Cloud אל APIs & Services > Credentials ובוחרים את מזהה לקוח OAuth של לקוח OAuth שבו נעשה שימוש במופע Looker (Google Cloud core).

  2. לוחצים על הלחצן הוספת URI כדי לעדכן את השדה מקורות מורשים של JavaScript בלקוח OAuth, כך שיכלול את אותו שם DNS שהארגון שלכם ישתמש בו כדי לגשת ל-Looker (Google Cloud core). לכן, אם הדומיין המותאם אישית שלכם הוא looker.examplepetstore.com, אתם מזינים את looker.examplepetstore.com כ-URI.

  3. מעדכנים או מוסיפים את הדומיין המותאם אישית לרשימת כתובות ה-URI המורשות להפניה אוטומטית של פרטי הכניסה ל-OAuth שבהם השתמשתם כשיצרתם את מופע Looker (Google Cloud core). מוסיפים /oauth2callback לסוף ה-URI. לכן, אם הדומיין המותאם אישית שלכם הוא looker.examplepetstore.com, אתם מזינים looker.examplepetstore.com/oauth2callback.

הוספת משתמשים

אחרי שמשלימים את השלבים הקודמים, כתובת ה-URL של הדומיין המותאם אישית נגישה למשתמשים.

לפני שמוסיפים משתמשים למופע Looker (Google Cloud core), צריך לוודא ששיטת אימות המשתמשים מוגדרת באופן מלא עבור המופע.

פתרון בעיות

  • אם אתם משתמשים ב-Chrome כדי לגשת לדומיין מותאם אישית של Looker (Google Cloud core) ואתם מקבלים שגיאה ב-Chrome, כמו NET::ERR_CERT_COMMON_NAME_INVALID או שגיאה במדיניות HSTS, אתם יכולים לפתור אותה באמצעות השלבים הבאים:

    1. פתיחת chrome://net-internals/#hsts
    2. מזינים את הדומיין המותאם אישית כדי לשלוח שאילתה לגבי ערכת ה-HSTS/PKP. כל כללי המדיניות של הדומיין המותאם אישית יופיעו בקטע נמצאו:.
    3. בקטע מחיקת מדיניות אבטחה של דומיין, מזינים את הדומיין המותאם אישית בשדה דומיין.
    4. לוחצים על מחיקה כדי למחוק את המדיניות.

  • כדי לפתור בעיות שקשורות לאישורים, אפשר לעיין בדף התיעוד בנושא פתרון בעיות שקשורות לאישורי SSL. באישורים שמנוהלים על ידי Google, חשוב לאשר באופן מפורש את רשות האישורים שרוצים לאפשר לה הנפקת אישור שמנוהל על ידי Google.

המאמרים הבאים