דרישות התקנה

דרישות חומרה

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

בסרטון הבא מפורטות הנחיות ברמה גבוהה לגבי הגודל של ההתקנה:

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

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

רכיב ההתקנה RAM CPU נפח דיסק קשיח מינימלי
Cassandra 16GB 8 ליבות אחסון מקומי בנפח 250GB עם כונן SSD שתומך ב-2,000 IOPS
מעבד/נתב הודעות באותה מכונה 16GB 8 ליבות 100GB
Message Processor (כרישיון נפרד) 16GB 8 ליבות 100GB
נתב (עצמאי) 16GB 8 ליבות 100GB
Analytics –‏ Postgres/Qpid באותו שרת 16GB‏* 8 ליבות* אחסון ברשת בנפח 500GB עד 1TB*****, רצוי עם קצה עורפי מסוג SSD, שתומך ב-1,000 IOPS או יותר*
Analytics – שרת ראשי או שרת זמין (standalone) של Postgres 16GB‏* 8 ליבות* אחסון ברשת בנפח 500GB עד 1TB*****, רצוי עם קצה עורפי מסוג SSD, שתומך ב-1,000 IOPS או יותר*
Analytics – Qpid עצמאי 8GB 4 ליבות אחסון מקומי בנפח 30GB עד 50GB עם SSD

גודל התור שמוגדר כברירת מחדל ב-Qpid הוא 1GB, ואפשר להגדיל אותו ל-2GB. אם אתם זקוקים לקיבולת גדולה יותר, תוכלו להוסיף צמתים נוספים של Qpid.
שרת OpenLDAP/UI/Management 8GB 4 ליבות 60GB
שרת UI/ניהול 4GB 2 ליבות 60GB
OpenLDAP (עצמאי) 4GB 2 ליבות 60GB

* שינוי דרישות המערכת של Postgres על סמך תפוקת הנתונים:

  • פחות מ-250 TPS: אפשר להשתמש במכונה עם 8GB ו-4 ליבות עם אחסון מנוהל ברשת*** שתומך ב-1, 000 IOPS ומעלה
  • יותר מ-250 TPS: אחסון מנוהל ברשת בנפח 16GB עם 8 ליבות*** התומך ב-1,000 IOPS ומעלה
  • יותר מ-1, 000 TPS: אחסון מנוהל ברשת עם 8 ליבות בנפח 16GB*** עם תמיכה ב-2, 000 IOPS או יותר
  • יותר מ-2, 000 TPS: אחסון מנוהל ברשת בנפח 32GB עם 16 ליבות*** שתומך ב-2, 000 IOPS או יותר
  • יותר מ-4, 000 TPS: אחסון מנוהל ברשת בנפח 64GB עם 32 ליבות*** שתומך ב-4, 000 IOPS או יותר

** הערך של דיסק הקש של Postgres מבוסס על ניתוח הנתונים המובנה ש-Edge מתעד. אם מוסיפים ערכים מותאמים אישית לנתוני Analytics, צריך להגדיל את הערכים האלה בהתאם. כדי להעריך את נפח האחסון הנדרש, משתמשים בנוסחה הבאה:

bytes of storage needed =

  (# bytes of analytics data/request) *

  (requests/second) *

  (seconds/hour) *

  (hours of peak usage/day) *

  (days/month) *

  (months of data retention)

לדוגמה:

(2K bytes) * (100 req/sec) * (3600 secs/hr) * (18 peak hours/day) * (30 days/month) * (3 months retention)

= 1,194,393,600,000 bytes or 1194.4 GB of storage needed

*** מומלץ להשתמש ב-Network Storage למסד הנתונים של Postgresql כי:

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

בנוסף, אלה דרישות החומרה הנדרשות כדי להתקין את שירותי המונטיזציה (לא נתמכים בהתקנה של All-in-One):

רכיב עם מונטיזציה RAM CPU דיסק קשיח
שרת ניהול (עם שירותי מונטיזציה) 8GB 4 ליבות 60GB
Analytics –‏ Postgres/Qpid באותו שרת 16GB 8 ליבות אחסון ברשת בנפח 500GB עד 1TB, רצוי עם קצה עורפי מסוג SSD שתומך ב-1, 000 IOPS או יותר, או שימוש בכלל שמופיע בטבלה שלמעלה.
Analytics – שרת ראשי או שרת ניצב עצמאי של Postgres 16GB 8 ליבות אחסון ברשת בנפח 500GB עד 1TB, רצוי עם קצה עורפי מסוג SSD שתומך ב-1, 000 IOPS או יותר, או שימוש בכלל שמופיע בטבלה שלמעלה.
Analytics – Qpid עצמאי 8GB 4 ליבות אחסון מקומי בנפח 40GB עד 500GB עם כונן SSD או HDD מהיר

להתקנות של יותר מ-250 בקשות לשנייה, מומלץ להשתמש בדיסק קשיח עם אחסון מקומי שתומך ב-1,000 פעולות קלט/פלט לשנייה (IOPS).

דרישות רוחב הפס של רשת Cassandra

Cassandra משתמשת בפרוטוקול Gossip כדי להחליף מידע עם צמתים אחרים לגבי טופולוגיית הרשת. השימוש ב-Gossip, בשילוב עם האופי המבוזר של Cassandra – שכרוך בתקשורת עם כמה צמתים לצורך פעולות קריאה וכתיבה – מוביל להעברת נתונים משמעותית ברשת.

כדי להשתמש ב-Cassandra, נדרש רוחב פס מינימלי של 1Gbps לכל צומת. להתקנות בסביבת הייצור מומלץ להשתמש ברוחב פס גבוה יותר.

זמן האחזור המקסימלי או הזמן החציוני ב-99% של Cassandra צריך להיות פחות מ-100 אלפיות השנייה.

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

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

דרישה מוקדמת: הפעלת המאגר EPEL

לפני שממשיכים בהתקנה, צריך לוודא שהמאגר EPEL (Extra Packages for Enterprise Linux) מופעל. משתמשים בפקודות הבאות בהתאם לגרסה של מערכת ההפעלה:

  • ב-Red Hat/CentOS/Oracle 8.X: 
    wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
    sudo rpm -ivh epel-release-latest-8.noarch.rpm
  • ב-Red Hat/CentOS/Oracle 9.X: 
    wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
    sudo rpm -ivh epel-release-latest-9.noarch.rpm

Java

לפני ההתקנה, צריך להתקין בכל מכונה גרסה נתמכת של Java 1.8. גרסאות ה-JDK הנתמכות מפורטות בקטע תוכנות וגרסאות נתמכות.

מוודאים שמשתנה הסביבה JAVA_HOME מפנה לשורש של ה-JDK של המשתמש שמבצע את ההתקנה.

SELinux

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

יצירת המשתמש 'apigee'

תהליך ההתקנה יוצר משתמש מערכת ב-Unix בשם 'apigee'. הספריות והקבצים של Edge הם בבעלות apigee, וכך גם התהליכים של Edge. כלומר, רכיבי Edge פועלים בתור המשתמש 'apigee'. אם יש צורך, אפשר להריץ רכיבים בתור משתמש אחר.

ספריית ההתקנה

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

בהוראות במדריך הזה, ספריית ההתקנה מסומנת בתור /opt/apigee.

לפני שיוצרים את הקישור הלא ישיר, צריך ליצור משתמש וקבוצה בשם apigee. זוהי אותה קבוצה והאותו משתמש שנוצרו על ידי מנהל ההתקנה של Edge.

כדי ליצור את הקישור הלא ישיר, מבצעים את השלבים הבאים לפני שמורידים את הקובץ bootstrap_4.53.00.sh. צריך לבצע את כל השלבים האלה כמשתמשים עם הרשאת root:

  1. יוצרים את המשתמש והקבוצה 'apigee': 
    groupadd -r apigee > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee
  2. יוצרים קישור סימבולי מ-/opt/apigee לשורש ההתקנה הרצוי: 
    ln -Ts /srv/myInstallDir /opt/apigee

    כאשר /srv/myInstallDir הוא המיקום הרצוי של קובצי Edge.

  3. משנים את הבעלות על ה-root של ההתקנה ועל הקישור הלא ישיר למשתמש 'apigee': 
    chown -h apigee:apigee /srv/myInstallDir /opt/apigee

הגדרת רשת

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

  • hostname מחזירה את שם המכונה
  • הפונקציה hostname -i מחזירה את כתובת ה-IP של שם המארח שאפשר לשלוח אליו הודעות ממכונות אחרות.

בהתאם לסוג ולגרסה של מערכת ההפעלה, יכול להיות שתצטרכו לערוך את /etc/hosts ו-/etc/sysconfig/network אם שם המארח לא מוגדר בצורה נכונה. מידע נוסף זמין במסמכי התיעוד של מערכת ההפעלה הספציפית.

אם לשרת יש כמה כרטיסי ממשק, הפקודה hostname -i מחזירה רשימה של כתובות IP מופרדות באמצעות רווחים. כברירת מחדל, מנהל ההתקנה של Edge משתמש בכתובת ה-IP הראשונה שמוחזרת, ויכול להיות שהיא לא נכונה בכל המצבים. לחלופין, אפשר להגדיר את המאפיין הבא בקובץ התצורה של ההתקנה:

ENABLE_DYNAMIC_HOSTIP=y

כשהמאפיין הזה מוגדר ל-'y', במהלך ההתקנה תופיע בקשה לבחור את כתובת ה-IP שבה רוצים להשתמש. ערך ברירת המחדל הוא 'n'. מידע נוסף זמין במאמר חומר עזר בנושא קובץ תצורה של Edge.

חבילות TCP

חבילות TCP Wrappers יכולות לחסום תקשורת של יציאות מסוימות, ויכולות להשפיע על התקנת OpenLDAP, ‏ Postgres ו-Cassandra. בצמתים האלה, בודקים את /etc/hosts.allow ו-/etc/hosts.deny כדי לוודא שאין הגבלות על יציאות OpenLDAP,‏ Postgres ו-Cassandra הנדרשות.

iptables

מוודאים שאין כללי מדיניות של iptables שמונעים קישוריות בין צמתים ביציאות Edge הנדרשות. אם צריך, אפשר לעצור את iptables במהלך ההתקנה באמצעות הפקודה:

sudo/etc/init.d/iptables stop

גישה לספרייה

בטבלה הבאה מפורטים ספריות בצמתים של Edge שיש להן דרישות מיוחדות מתהליכי Edge:

שירות ספרייה תיאור
נתב /etc/rc.d/init.d/functions

Edge Router משתמש בנתב Nginx ודורש הרשאת קריאה ל-/etc/rc.d/init.d/functions.

אם תהליך האבטחה שלכם מחייב להגדיר הרשאות ב-/etc/rc.d/init.d/functions, אל תגדירו אותן לערך 700, אחרת הנתב לא יופעל.

אפשר להגדיר את ההרשאות ל-744 כדי לאפשר גישה לקריאה ל-/etc/rc.d/init.d/functions.
Zookeeper /dev/random ספריית הלקוח של Zookeeper דורשת הרשאת קריאה למחולל המספרים האקראיים /dev/random. אם /dev/random חסום לקריאה, יכול להיות ששירות Zookeeper לא יופעל.

Cassandra

כל צמתים של Cassandra חייבים להיות מחוברים ל-ring. Cassandra שומרת רפליקות של נתונים במספר צמתים כדי להבטיח אמינות ועמידות בכשלים. שיטת היצירה של רפליקות בכל מרחבי המפתחות של Edge קובעת את צמתים של Cassandra שבהם הן ממוקמות. מידע נוסף זמין במאמר מידע על גורם הרפליקציה ורמת העקביות של Cassandra.

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

אחרי התקנת Edge for Private Cloud, אפשר לבדוק אם Cassandra מוגדרת בצורה נכונה על ידי בדיקת הקובץ /opt/apigee/apigee-cassandra/conf/cassandra.yaml. לדוגמה, מוודאים שסקריפט ההתקנה של Edge for Private Cloud מגדיר את המאפיינים הבאים:

  • cluster_name
  • initial_token
  • partitioner
  • seeds
  • listen_address
  • rpc_address
  • snitch

מסד נתונים של PostgreSQL

אחרי שתתקינו את Edge, תוכלו לשנות את ההגדרות הבאות של מסד הנתונים PostgreSQL בהתאם לכמות ה-RAM שזמינה במערכת:

conf_postgresql_shared_buffers = 35% of RAM      # min 128kB
conf_postgresql_effective_cache_size = 45% of RAM
conf_postgresql_work_mem = 512MB       # min 64kB

כדי להגדיר את הערכים האלה:

  1. עורכים את הקובץ postgresql.properties: 
    vi /opt/apigee/customer/application/postgresql.properties

    אם הקובץ לא קיים, יוצרים אותו.

  2. מגדירים את המאפיינים שמפורטים למעלה.
  3. שומרים את השינויים.
  4. מפעילים מחדש את מסד הנתונים של PostgreSQL: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

הגדרת שפה ואזור ב-Rocky 9.X

אם אתם משתמשים ב-Rocky 9.X, ודאו שהמערכת מוגדרת עם LANG=en_US.utf8 בהגדרות הלוקאל ברמת המערכת. כדי להגדיר את זה, מריצים את הפקודות הבאות:

dnf -y -q install langpacks-en
localectl set-locale LANG=en_US.utf8
reboot

מגבלות מערכת

חשוב לוודא שהגדרתם את מגבלות המערכת הבאות בצמתים של Cassandra ושל Message Processor:

  • בצמתים של Cassandra, מגדירים את המגבלות הרכות והקשות של memlock, ‏ nofile ו-address space (as) למשתמש ההתקנה (ברירת המחדל היא 'apigee') בקובץ /etc/security/limits.d/90-apigee-edge-limits.conf, כפי שמתואר בהמשך: 
    apigee soft memlock unlimited
apigee hard memlock unlimited
apigee soft nofile 32768
apigee hard nofile 65536
apigee soft as unlimited
apigee hard as unlimited
apigee soft nproc 32768
apigee hard nproc 65536
  • בצמתים של Message Processor, מגדירים את המספר המקסימלי של מתארי קבצים פתוחים ל-64K ב-/etc/security/limits.d/90-apigee-edge-limits.conf כפי שמתואר בהמשך: 
    apigee soft nofile 32768
apigee hard nofile 65536

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

  • אם השגיאה הבאה מופיעה בחיבור לרשת או במעבד הודעות system.log, יכול להיות שהמגבלות של מתאר הקובץ מוגדרות נמוכות מדי:

    "java.io.IOException: Too many open files"

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

    # su - apigee
$ ulimit -n
100000

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

Network Security Services‏ (NSS)

Network Security Services‏ (NSS) היא קבוצה של ספריות שתומכות בפיתוח של אפליקציות לקוח ושרת עם אבטחה מובנית. צריך לוודא שהתקנתם את NSS בגרסה 3.19 ואילך.

כדי לבדוק את הגרסה הנוכחית:

yum info nss

כדי לעדכן את NSS:

yum update nss

מידע נוסף זמין במאמר הזה של RedHat.

השבתת חיפוש DNS ב-IPv6 כשמשתמשים ב-NSCD (Name Service Cache Daemon)

אם התקנתם והפעלתם את NSCD‏ (Name Service Cache Daemon), מעבדי ההודעות מבצעים שתי בדיקות DNS: אחת ל-IPv4 ואחת ל-IPv6. כשמשתמשים ב-NSCD, צריך להשבית את בדיקת ה-DNS ב-IPv6.

כדי להשבית את חיפוש ה-DNS ב-IPv6:

  1. בכל צומת של Message Processor, עורכים את /etc/nscd.conf
  2. מגדירים את המאפיין הבא: 
    enable-cache hosts no

השבתת IPv6 ב-RHEL 8 ואילך

אם מתקינים את Edge ב-RHEL 8 ואילך ב-Google Cloud Platform, צריך להשבית את IPv6 בכל צמתים של Qpid.

הוראות להשבתת IPv6 מפורטות במסמכים של ספק מערכת ההפעלה. לדוגמה, מידע רלוונטי זמין במסמכי התיעוד של Red Hat Enterprise Linux.

כלים

תוכנת ההתקנה משתמשת בכלי ה-UNIX הבאים בגרסה הרגילה שסופקו על ידי EL5 או EL6.

awk

expr

libxslt

RPM

לחלץ את הקובץ

basename

grep

lua-socket

rpm2cpio

useradd

bash

 hostname

ls

sed

wc

bc

id [מזהה]

net-tools

sudo

wget

curl

libaio

perl (מ-procps)

tar

xerces-c
cyrus-sasl libdb4 pgrep (מ-procps) tr טעים

תאריך

 libdb-cxx

ps

uuid

chkconfig
dirname libibverbs pwd uname  
echo librdmacm python    

סנכרון זמן

מומלץ לסנכרן את השעונים של השרתים ב-Apigee. אם עדיין לא הגדרתם את השירות, תוכלו להשתמש בכלי ntpdate או בכלי מקביל כדי לוודא שהשעון של השרתים מסונכרן. לדוגמה, אפשר להשתמש בפקודה yum install ntp או בפקודה מקבילת כדי להתקין את השירות. האפשרות הזו שימושית במיוחד ליצירת רפליקה של הגדרות OpenLDAP. חשוב לזכור שצריך להגדיר את אזור הזמן של השרת ל-UTC.

openldap 2.4

כדי להתקין את ה-API בארגון צריך את OpenLDAP 2.4, שמופיע במאגר apigee-thirdparty-opdk. כדי להקל על ההתקנה, צריך להסיר את הספרייה openldap-compat.

בהתקנות עם 13 מארחים ובהתקנות עם 12 מארחים ושני מרכזי נתונים, יש צורך ברפליקציה של OpenLDAP כי יש כמה צמתים שמארחים את OpenLDAP.

חומות אש ומארחים וירטואליים

המונח virtual נתון לעומס יתר בתחום ה-IT, וכך גם לגבי פריסה של Apigee Edge לענן פרטי ומארחים וירטואליים. לשם הבהרה, יש שני שימושים עיקריים למונח virtual:

  • מכונות וירטואליות (VM): לא חובה, אבל בחלק מהפריסות נעשה שימוש בטכנולוגיית VM כדי ליצור שרתים מבודדים לרכיבי Apigee. למארחי מכונות וירטואליות, כמו למארחים פיזיים, יכולים להיות ממשקי רשת וחומת אש.
  • מארחים וירטואליים: נקודות קצה באינטרנט, בדומה למארח וירטואלי של Apache.

נתב במכונה וירטואלית יכול לחשוף כמה מארחים וירטואליים (כל עוד הם שונים זה מזה בשם החלופי של המארח או ביציאת הממשק שלהם).

לדוגמה, בשרת פיזי יחיד A יכולים לפעול שני מכונות וירטואליות, בשמות VM1 ו-VM2. נניח ש-VM1 חושף ממשק Ethernet וירטואלי שנקרא 'eth0' בתוך המכונה הווירטואלית, ושמוקצית לו כתובת IP‏ 111.111.111.111 על ידי המכונה לווירטואליזציה או שרת DHCP ברשת. נניח גם ש-VM2 חושף ממשק Ethernet וירטואלי שנקרא גם 'eth0', ושמוקצית לו כתובת IP‏ 111.111.111.222.

יכול להיות שנפעיל נתב Apigee בכל אחת משתי המכונות הווירטואליות. הנתב חושף נקודות קצה של המארח הווירטואלי, כמו בדוגמה הזו:

הנתב של Apigee ב-VM1 חושף שלושה מארחים וירטואליים בממשק eth0 שלו (שיש לו כתובת IP ספציפית כלשהי), api.mycompany.com:80,‏ api.mycompany.com:443 ו-test.mycompany.com:80.

הנתב ב-VM2 חושף את api.mycompany.com:80 (אותו שם ואותה יציאה כמו שמוחשפים ב-VM1).

יכול להיות שמערכת ההפעלה של המארח הפיזי כוללת חומת אש ברשת. במקרה כזה, צריך להגדיר את חומת האש כך שתאפשר מעבר של תעבורת TCP שמקושרת ליציאות שנחשפות בממשקים הווירטואליים (111.111.111.111:{80, 443} ו-111.111.111.222:80). בנוסף, יכול להיות שמערכת ההפעלה של כל מכונה וירטואלית תספק חומת אש משלה בממשק eth0, וגם חומות האש האלה צריכות לאפשר חיבור של תעבורת נתונים ביציאות 80 ו-443.

נתיב הבסיס הוא הרכיב השלישי שמעורב בחיבור קריאות ל-API לשרתים שונים של proxy ל-API, שאולי פרסתם. חבילות proxy של API יכולות לשתף נקודת קצה אם יש להן נתיבי בסיס שונים. לדוגמה, אפשר להגדיר נתיב בסיס אחד בתור http://api.mycompany.com:80/ נתיב בסיס אחר בתור http://api.mycompany.com:80/salesdemo.

במקרה כזה, צריך מאזן עומסים או מנהל תעבורה כלשהו שיחלק את התנועה של http://api.mycompany.com:80/ בין שתי כתובות ה-IP (111.111.111.111 ב-VM1 ו-111.111.111.222 ב-VM2). הפונקציה הזו ספציפית להתקנה הספציפית שלכם, והיא מוגדרת על ידי קבוצת הרשתות המקומית.

נתיב הבסיס מוגדר כשפורסים ממשק API. לפי הדוגמה שלמעלה, אפשר לפרוס שני ממשקי API,‏ mycompany ו-testmycompany, לארגון mycompany-org באמצעות המארח הווירטואלי עם הכינוי api.mycompany.com והיציאה 80. אם לא מגדירים נתיב בסיס בפריסה, הנתב לא יודע לאיזה API לשלוח את הבקשות הנכנסות.

עם זאת, אם פורסים את ה-API testmycompany עם כתובת ה-URL הבסיסית /salesdemo, המשתמשים יגיעו ל-API הזה דרך http://api.mycompany.com:80/salesdemo. אם פורסים את ה-API mycompany עם כתובת ה-URL הבסיסית /, המשתמשים יגיעו ל-API דרך כתובת ה-URL http://api.mycompany.com:80/.

רישוי

לכל התקנה של Edge נדרש קובץ רישיון ייחודי שמקבלים מ-Apigee. תצטרכו לציין את הנתיב לקובץ הרישיון בזמן התקנת שרת הניהול, לדוגמה ‎/tmp/license.txt.

מנהל ההתקנה מעתיק את קובץ הרישיון אל /opt/apigee/customer/conf/license.txt.

אם קובץ הרישיון תקין, שרת הניהול מאמת את התוקף ואת מספר מעבדי ההודעות (MP) המותרים. אם תוקף ההגדרות של הרישיון פג, היומנים נמצאים במיקום הבא: /opt/apigee/var/log/edge-management-server/logs. במקרה כזה, אפשר לפנות אל התמיכה של Apigee Edge לקבלת פרטי ההעברה.

אם עדיין אין לכם רישיון, פנו אל מחלקת המכירות של Apigee.